Mp3 dir and database issue

[Anonymous]

Hi,
I have found out that i some times have problems playing my songs, FF just can not find some of them some times.

I had one album with Mötley Crüe and it was found but it could not be scanned because the tags were unreadable. I have several other albums with the same group and these are no problem to read. This problem was solved by just renaming the file and remove the ü

Anyway, when i was trying to solve this problem i found some interesting information in “mt-daapd.conf”, saying the following:

# mp3_dir (required)

#

# Location of the mp3 files to share.  Note that because the

# files are stored in the database by inode, these must be

# in the same physical filesystem.

Does this mean that i have to have the database file and the music files on the same physical disc???

And one more thing, my database was set to sqlite3 by default but the “mt-daapd.conf” says that sqlite is more stable, should i change it???

Thanks in advance for your help.

[stretch]

Depends on what version & what platform Firefly is running on.

svn1696 is more stable when using sqlite3
The inode comment is only applicable to version 0.2.4.x
Firefly has problems with non-ASCII characters

[Anonymous]

Thanks for your quick reply.

I’m trying with sqlite instead now and so far it looks good.

Because i’m running Firefly on a basic Windows XP (Sp3) i downloaded Firefly svn-1586 (it was the most stable one according to the notes).
But my music files are located on a “Lacie Networkspace Drive” which is Linux based.

Is the problem with the non ASCII characters fixable within the database or is the problem in fact in Firefly?

[stretch]

@WilsonTobbe wrote:

But my music files are located on a “Lacie Networkspace Drive” which is Linux based.

The NAS operating system is irrelevant. XP sees it as a network drive.

@WilsonTobbe wrote:

Is the problem with the non ASCII characters fixable within the database or is the problem in fact in Firefly?

Firefly sometimes chokes & crashes when it encounters on non-ASCII characters during the database build / update process. The db is left corrupted and incomplete when this occurs.

[Anonymous]

And now i have been using the sqlite database instead of sqlite3 for a couple of days and at first it all looked good but now i have noticed that it looks like Firefly is first dumping the database and the rescanning it again from time to time.
It has happaned twice now, when i look for files in my Roku they are not there and after checking the Firefly i see that it’s adding the songs.
Why is it doing this when they are allready there?
The log looks ok i think…

[stretch]

Firefly does a rescan when you restart the server, it also periodically scans the library for new music, configurable via the rescan interval.
Both can be disabled if you so desire.

The first is disabled via the Initial Scan option in the advanced configuration section.
The periodic rescan can be disabled by setting the rescan interval time to zero.

[Anonymous]

Yes i know it does a rescan when i restart my server but the server was not restarted and i also know about the setting for periodically scanning for new music.
Both of these funtions worked fine using sqlite3, but when i use sqlite the database is first dumped before the library is rescanned meaning that according to my Roku my library is empty for a while. This has never happend with sqlite3.

But to sure that it was not a misstake from me i also changed the scan interval from the default 600 to 4800 because my libray is quite large and 600 is far too short time for it to be able to read the library.

[Author]

Posts