@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