SMPlayer 16.8 and 16.9 Playlist regression

[DVV]

I've seemed to find a regression in SMPlayer's Playlist in versions 16.8 and 16.9.
Steps to reproduce:
1. Consider having the following files in a folder:
Movie.S01E01.mkv
Movie.S01E02.mkv
Movie.S01E03.mkv
Movie.S01E04.mkv
Movie.S01E05.mkv
Movie.S01E06.mkv
2. I'm starting SMPlayer by double-clicking "Movie.S01E01.mkv".
3. Then I manually add the rest of the files to the Playlist, in the same order as mentioned above.
4. Then I proceed to the next file, Movie.S01E02.mkv, and pause it during the playback.
5. Then I restart SMPlayer (exit it and start again).
The expected behavior: SMPlayer's Playlist should be at Movie.S01E02.mkv, where it was paused.
The actual behavior: SMPlayer's Playlist is at Movie.S01E05.mkv. (???)

[rvm]

I cannot reproduce the problem. For me the the selected file after the restart is the 2nd file, as expected.

[DVV]

Tried on on different PCs - one with Windows 7 64-bit, another one with Windows 8.1 64-bit.
Tried with 32-bit SMPlayer 16.8 and 16.9, both with my old SMPlayer.ini and without it.
Each time the issue is constantly reproduced for me.
Actually I have an impression that the position in the Playlist becomes reversed:
- e.g. if I close SMPlayer at the first item in the Playlist, it will be re-opened at the last item (i.e. first from the end);
- if I close it at the 2nd item, it will be opened at the 2nd item from the end;
- and so on.
Could it be a bug of QT 5 in Windows?

[rvm]

I was able to reproduce the problem but only once.

[DVV]

Also, looking at the content of the file "playlist.ini", I can see that the value of "current_item" under [playlist_contents] seems to be always randomly changed each time when I open and then immediately close SMPlayer. At least, I can't see any logic in these changes. This value could be saved as 6; after the next restart it could be 5; after the next restart 6 again; then 5; then 4...
Doesn't it look like a non-properly initialized variable maybe? Or maybe it's something related to 0-based and 1-based indexing that is mixed?

[rvm]

Does it still happen in the development version?
https://sourceforge.net/projects/smplay ... /Unstable/

[DVV]

Tried with SMPlayer 16.9.0, revision 8224, 32-bit.
I see very stable and predictable behavior while observing the value "current_item" inside the "playlist.ini" file.
What I did:
1. Start SMPlayer with 10 items in its Playlist (inside "playlist.ini" it says items\size=10);
2. Select some initial item in the playlist (in Case 1 I've selected the 1st item; in Case 2 I've selected 3rd item) and close SMPlayer;
3. Start SMPlayer without doing anything in it; exit SMPlayer; observe changes in "playlist.ini";
4. Start SMPlayer without doing anything in it; exit SMPlayer; observe changes in "playlist.ini";
5. Start SMPlayer without doing anything in it; exit SMPlayer; observe changes in "playlist.ini";
6. and so on...

Here are the results.
Notice that items\size=10 always.
The value of current_item is changed each time SMPlayer exits.
Case 1: how current_item value is changed: 0 -> 9 -> 0 -> 9 -> 0 -> 9
Case 2: how current_item value is changed: 2 -> 7 -> 2 -> 7 -> 2 -> 7

I believe the "logic" is clear now: after each restart the value of current_item becomes (size - current_item - 1).

[rvm]

I still can't reproduce it. What options are you using in preferences -> playlist?

[DVV]

Please find the screenshot SMPlayer-Preferences-Playlist.png attached.

Preferences - Playlist

SMPlayer-Preferences-Playlist.png (33.16 KiB) Viewed 1610 times

[DVV]