FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › General Discussion › Bug: mt-daapd can not notice the change of mp3 file name
- This topic has 6 replies, 3 voices, and was last updated 17 years, 2 months ago by fizze.
-
AuthorPosts
-
08/08/2007 at 10:06 AM #1618wordwormParticipant
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 ๐08/08/2007 at 11:07 AM #12020fizzeParticipantthats 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 intouch A.mp3
09/08/2007 at 3:08 AM #12021rpeddeParticipant@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 itAt some point, it will probably get added, but it won’t be in the immediate term unless someone contributes a patch.
— Ron
10/08/2007 at 9:18 AM #12022wordwormParticipantI 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.
10/08/2007 at 9:54 AM #12023wordwormParticipantI 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.
11/08/2007 at 3:06 AM #12024rpeddeParticipant@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
11/08/2007 at 7:30 AM #12025fizzeParticipant…and just in time for the fresh nightly ๐
*crosses fingers* -
AuthorPosts
- The forum ‘General Discussion’ is closed to new topics and replies.