Bug: mt-daapd can not notice the change of mp3 file name

[wordworm]

For example, there’re A.mp3 in mp3 folder of mt-daapd, and itunes can playback it.
If you change the file name from A.mp3 to B.mp3 on the server, and let mt-daapd do “rescan” through its web adminitrative page. mt-daapd will not notice this kind of change, and the db will not update. In its db, it still record A.mp3, and Itunes can not playback the mp3.
I notice that mt-daapd only can notice the file add or remove, not the file name change.
If I delete the songs.db, and restart mt-daapd, it will recreate songs.db, and the renamed song can be playbacked.

Do you have met this kind of bugs?
How does it do “rescan” ?
Thanks 😀

[fizze]

thats exaclty what a “rescan” does. It will only notice completely new files, or files where the contents have changed since the last scan.

You want to do a “full rescan”, that essentialyl drops the DB, and rebuilsd its contents from scratch.

As a workaround, change the timestamp of the file, so mt-daapd notices there is a difference 😉
as in

touch A.mp3

[rpedde]

@wordworm wrote:

For example, there’re A.mp3 in mp3 folder of mt-daapd, and itunes can playback it.
If you change the file name from A.mp3 to B.mp3 on the server, and let mt-daapd do “rescan” through its web adminitrative page. mt-daapd will not notice this kind of change, and the db will not update. In its db, it still record A.mp3, and Itunes can not playback the mp3.
I notice that mt-daapd only can notice the file add or remove, not the file name change.
If I delete the songs.db, and restart mt-daapd, it will recreate songs.db, and the renamed song can be playbacked.

Do you have met this kind of bugs?
How does it do “rescan” ?
Thanks 😀

It should. The only time I’ve seen that is on FAT32 drives. The reason being is that FAT32 doesn’t hold UTC timestamps, so times are often off. Sometimes on FAT32 drives it might take as long as whatever your offset is from UTC to see a file system change.

Not a lot to be done about it. I could add logic to detect drive type and convert from local to UTC, but that’s a lot of work and I just haven’t sat down to do it because:

1. Fat32? Really?
2. Lots of work, and a rescan fixes it

At some point, it will probably get added, but it won’t be in the immediate term unless someone contributes a patch.

— Ron

[wordworm]

I test it on Fedora Core 5, it’s ext3 file system.

It use Local Time.

If I changes a mp3 file name, and let do “rescan”. It will not update the db. In Itunes I can see the old filename, and can not playback it.

[wordworm]

I found that if you use “mv” to change the file name, and you “stat” it.
You will find the
Last Modify time does not changed.
Last Change time will change.

So we may use “Last Change time” to decide whether the file has change or not.

[rpedde]

@wordworm wrote:

I found that if you use “mv” to change the file name, and you “stat” it.
You will find the
Last Modify time does not changed.
Last Change time will change.

So we may use “Last Change time” to decide whether the file has change or not.

I thought I *was* using ctime, but I’ll double-check.

— Ron

[fizze]

…and just in time for the fresh nightly 🙂
*crosses fingers*

[Author]

Posts