Page 1 of 1

Resume (audio) seems to do this by file name only - please add a checksum

Posted: 26 May 2022 17:59
by JanDoggen
I have noticed several times (currently 3.3.4 on Android 10, but I've seen it in earlier versions) that an audio file starts playing in the middle. This is the scenario:

1. Copy a sequence of mp3 files to my phone. Let's say files named F1, F2, F3, F4, F5
2. I do 'play all' from file F1 (no play lists, just from SD card), and for some reason stop playing F3 halfway (maybe skip to F4 because not interesting enough)
3. Remove F1..F5 and place new files in the same folder named F6, F3, F7, F8
4. Start playing from F6.

Now when F6 is done, VLC starts playing F3 from the point where I stopped it, not from its start. Again, it's a totally different file, it only has the same name F3. (Some RSS feeds do that, they always download identical file names)

It looks as if VLC associates the resume point with file name only. That should be changed to e.g. filename+CRC.

Re: Resume (audio) seems to do this by file name only - please add a checksum

Posted: 27 May 2022 13:44
by Spike1
There's two things happening here:
① Mistakenly starting a track in the middle based on a previous play. This has been addressed and corrected.
② Treating a file as identical to a deleted file by the same name: This is the sensible behavior; I wouldn't want the performance hit of having VLC read all of F3 to see if it's the same as a past file named F3. Not a problem if ① is fixed.

Re: Resume (audio) seems to do this by file name only - please add a checksum

Posted: 29 May 2022 12:27
by JanDoggen
Then use the file size. That's a 99.99% guarantee.

Re: Resume (audio) seems to do this by file name only - please add a checksum

Posted: 31 May 2022 07:37
by Aza
Spike1 is totally right about what happens. I pinged the person in charge of the medialibrary to have his thoughts about that.

Re: Resume (audio) seems to do this by file name only - please add a checksum

Posted: 31 May 2022 08:43
by chouquette
Indeed if the file has the same name, we will consider it to be the same media. We already check the file size/modification date and will refresh the file if it was modified on disk, but so far we don't discard progress and other user provided information when a change is detected.

I'm really not sure we want to do so either, the common use case I can think of when the file content changes but the file name stays the same is after an upgrade for some downloaded content. In this situation I don't think we want to discard progress & such info.

While it's easy to know if the file has changed, guessing if the change is minor (ie. a tag was updated or something) or if it's a completely different file is not that simple, and I don't think we should venture there

Re: Resume (audio) seems to do this by file name only - please add a checksum

Posted: 31 May 2022 11:37
by Spike1
I agree with Chouquette; filenames ought to be descriptive, and a new file with identical name should be presumed to be the same file.

Not so much for the fake filenames VLC creates (such as "fd://57") when it receives a handle to the file and does not have access to the real filename.

Re: Resume (audio) seems to do this by file name only - please add a checksum

Posted: 31 May 2022 14:46
by JanDoggen
That "file names should be descriptive" is not what happens. From the 43 RSS feeds that I follow here's the status:
- 18 have descriptive file names, that includes "Episode827" or "ABC2022-05-31"
- 11 have totally random file names. That includes all BBC podcasts
- 5 always have the same file name. Those were the reason for asking
-9 I could not determine because they currently contain no entries

Welcome to the real world ;-)
Luckily the MP3 tags are better.