Audio CD's

[OldJoe]

Hi all,

I want to play audio cd's via smplayer on a Raspberry with Raspian (Stretch). Just a simple thing, I thought ...
But every time I start a cd the result is not in the sort order like physical on cd. I have looked fpr "shuffle" but in smplayer gui there is nothing to unchoose that. Lastly I found 2 positions in the ini-files about shuffleing. In a ini is a entry "shuffle=false" ... sounds very well und in the second ini I found the parameter options for mplayer and have the "--shuffle" part eliminated.
But without result, the playing isn't in physical order again. With look on the shown sort order of the tracks, they are going 1, 10, 11, ..., 19, 2, 20, 21, ..., 23, 3, 4, 5, ..., 9. That looks as if the programmer made one of the oldest and most stupid developement errors ... numbers with different arity can't be directly compared in IT. You have to change them from string to real numbers (mathem.) or to equalize the arity, e.g. 01, 10, 11, 02, 20, ...

Can any one tell me a) if there is a solution by parametring in gui or b) if it's a idee to sort that crap in a third ini where I found this mismatch or is building smplayer that crap on every cd again on the fly.

And no hints to puzzle a playlist for playing in physical order ... a playlist for what is well sorted and documented is nonsense and against all for what IT is thought, to make life easier ...

So long Jo

[rvm]

Probably the playlist is sorted by name. Click on the header of the number column to change the order.

[OldJoe]

Good idea as such but normally I have no playlist made for the CD. Ok, could be I can change the autogenerated playlist of the program.
But I guess this will not solve the problem cause everytime the played order is Track 1, track 10, Track 11 ... track 19, Track 2, Track 20 ... Track 23 (or 22/24 depending on given number of titles on CD), Track 3, Track 4 ... Track 9. This happens with each CD.
And with look into that inifile where the first time cd-data is saved I see order numbers sorted from 1 to 23(22/24) with the wrongly sorted Track as name in each entry. So the sortig is by number and wrong and if sorting by name is possible the sorting will go over the names "Track x(x)" and that will result in the same wrong sorting as given by the number. In IT generelly a shorter entry with no difference over its length is in front of the longer and by same length the value is sorting. So looking on that "Track 1" is directly in front of "Track 11" and not "Track 2" cause the first both are identic for "Track 1" and with the second "1" the eleventh coms direct behind and not the "Track 2" which differs in the "2" after both with the "1". So the mistake is done and manifested by reading a CD for the first time. I'm not sure why the programmer is doing such a crap instead of reading the CD track by track and building the internal playlist in that pysical order if even neccessary.
The problem is the same as each Y2K developer was aware with date items. Taking day.month.year for sorting is giving big trouble. Either you take year.month.day or you generate a numbervalue for each datealso by int(year) + int(month) + int(day). But I have seen a lot of sources, ini's and such espeially on linux where it'S usuall to take 1, ..., 9, 10, 11, ... instead of the most sure 01, ..., 09, 10, 11, ... In that case you get entries of equal length and no problem with sorting them. On windows this much more often done so ...

[rvm]

It would be more helpful if you sent the logs so that the programmer could figure out where the problem is.

[OldJoe]

Thanks for the help but if things have to go to the programmers in my experience mostly nothing is coming quickly to the better side.
On other hand the problem is finished cause the complete project dropped, Tvheadend is having problems with the tv-stick, kodi is obsolete if the DVB-C-stick is in trouble and without kodi with it's problems to play everytime the audio-cd there is no further need for smplayer. I will use therefor VLC alone (video and audio) as on all my PC's and the problem is solved.