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

[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.

[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.

[JanDoggen]

Then use the file size. That's a 99.99% guarantee.

[Aza]

Spike1 is totally right about what happens. I pinged the person in charge of the medialibrary to have his thoughts about that.

[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

[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.

[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.