You are here: Home » Topic » Bug: mt-daapd can not notice the change of mp3 file name

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

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server General Discussion Bug: mt-daapd can not notice the change of mp3 file name

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #1618
    wordworm
    Participant

    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 😀

    #12020
    fizze
    Participant

    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
    #12021
    rpedde
    Participant

    @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

    #12022
    wordworm
    Participant

    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.

    #12023
    wordworm
    Participant

    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.

    #12024
    rpedde
    Participant

    @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

    #12025
    fizze
    Participant

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

Viewing 7 posts - 1 through 7 (of 7 total)
  • The forum ‘General Discussion’ is closed to new topics and replies.