[bug#8715] AutoPlaylists - Sort by Last Played

[markstuartwalker]

@Silver

From what I can see on your post there seems to be erroneous last played dates in the database. Dates are stored as a floating point number in the db. Numbers are stored with a ',' or '.' separator according to the locale set on the machine. I spent alot of time getting this right for various european users.

My suspicion is that you've changed locale at some point. Is this true?

If you play the track in question does the date get corrected? It should.

[Silver]

No, never changed my locale settings.
And yes, if I play the track in mediamonkey the date get changed to a correct value.

Here are the results using the SQL Viewer extension:

Code: Select all

SELECT SongTitle, LastTimePlayed FROM Songs ORDER BY LastTimePlayed DESC

Code: Select all

#	 SONGTITLE 									LASTTIMEPLAYED
...
11	Stay Awake									40860,6644444444 
12	Deeply Disturbed (Infected Remix) 	40853,9678819444 
13	Cara catastrofe 							40884.77511235
14	When We Stand Together					40884.769127859 
...
95	KARMA CHAMELEON							 40881.0 
96	BORN IN THE U.S.A.						 40881.0 
97	Never Let Me Down Again				  40881.0 
98	Raised On Rock							  40881.0 
99	T.N.T.										 40881.0
...

Song #13 was played a while ago with MM and has the correct value.
I notice there are also many songs with a null decimal part, it's surely an incorrect value 'cause it's practically impossible playing nearly 20 tracks at the same time!

[markstuartwalker]

So, if you deliberately played (say) song #99 it would become corrected .... if this is true then I'd suggest that the plugin is working correctly. The code has been unchanged in my MM4 code since I branched to v4.

It should be possible to do a bit of SQL to remedy the comma separated entries. Unfortunately not my area of expertise.

If you're interested my code which converts a date into a string for the database is this .. (note the use of MMInterf.Localize)

Code: Select all

function MMdateToFloatStr(d:Tdatetime):WideString;
var
  s:string;
  diff:Tdatetime;
begin
  try
    diff:=d-datetime0;
    s:=QuotedStr(MMInterf.Localize(floatToStr(double(diff))));
  except
    on e:exception do
    begin
      log.exception('MMdateToFloatStr',e);
      s:=QuotedStr(MMInterf.Localize(dateTimeToStr(datetime0())));
    end;
  end;
  Result:=s;

end;

function MMfloatStrToDate(s:WideString):Tdatetime;
var
  f:double;
  d:Tdatetime;
begin
  try
    f:=StrToFloat(replaceDecimalSymbol(s));
    f:=f+double(datetime0);
    //dim dd : dd = datediff("s",cdate("1899 12 30" ),d )/86400
    d:=Tdatetime(f);
  except
    on e:exception do
    begin
      log.exception('MMfloatStrToDate',e);
      d:=datetime0();
    end;
  end;
  Result:=d;
end;

[Silver]

Song #99 is already correct, although with no decimal part it's displayed correctly in MM.
Incorrect songs are #1 to #12. Those songs were played on an iphone and synced back to MM.

[markstuartwalker]

So, please tell me what locale are you using and what is the separator used for decimals? The plugin will do a pre-check and it's determining that you use a ','. Is this incorrect?

[Silver]

I'm currently using "Italian (Italy)" as the default locale in Windows.
I'm using English as display language for both Windows and MediaMonkey.
And yes, "," is the correct separator for the Italian locale.
The problem is that MM is actually using "." rather than "," for all values stored in the database. All values with a "," as a separator are displayed incorrectly.

[markstuartwalker]

At startup the plugin code does a check to try and convert a '123.456' string to a float. If it works then it's going to use '.' as the separator. If it fails then it assumes it needs to be ','.

Code: Select all

  // see what localisation works
  decimalSymbol:='.';
  try
    f:=StrToFloat('123.456');
  except
    decimalSymbol:=',';
  end;
  log.text(2,'Decimal Symbol',decimalSymbol);

When reading from the DB a field such as LASTTIMEPLAYED is read as a string. Any occurrences of the wrong separator is converted to the right one. This makes the plugin tolerant to reading either type of separator.

Code: Select all

function replaceDecimalSymbol(s:WideString):WideString;
begin
  if decimalSymbol='.' then
    Result:=StringReplace(s,',','.',[])
  else
    Result:=StringReplace(s,'.',',',[]);
end;

Now, when the plugin writes to the DB the float is converted to a string by using MM's Localize function.

Code: Select all

function MMdateToFloatStr(d:Tdatetime):WideString;
var
  s:string;
  diff:Tdatetime;
begin
    diff:=d-datetime0;
    s:=QuotedStr(MMInterf.Localize(floatToStr(double(diff))));
    Result:=s;
end;

And I think that is where the fault lies. The reading is handled by my bespoke code whereas the writing is handled by the Localize function. The Localize function will use the display language and I'm using the locale.

In all cases that I know my users have the same display language as their locale (or the separators for the two are the same anyway). You have a mix of Italian and English which have difference separators.

As a test can you set your display language to Italian and see in the correct separator is written into the database?

[markstuartwalker]

Ok, I've made some progress here. I manually set my decimal separator to ',' and the 1000s separator to '.'. Resultantly all sorts of exceptions popped out. The most obvious symptom was that the last played times were set to the date of last playing but time=00:00. This is what Silver reported - a secondary symptom was that the playlists were in the wrong order.

It would appear that MM wants the dates to ALWAYS have a '.' separator irrespective of it's locale or presentation settings. The new code looks like this.

Code: Select all

function MMdateToFloatStr(d:Tdatetime):WideString;
var
  s:string;
  diff:Tdatetime;
begin
  try
    diff:=d-datetime0;
    s:=QuotedStr(StringReplace(floatToStr(double(diff)),',','.',[]));
  except
    on e:exception do
    begin
      log.exception('MMdateToFloatStr',e);
      s:=QuotedStr('0.0');
    end;
  end;
  Result:=s;
end;

... and all seems well. I'm going to settle with this for now. So it will be in the next release.

[markstuartwalker]

Build 2238 released to fix this.

[Silver]

Fixed. Thank you mark!

[markstuartwalker]

It's a pleasure.

Can you keep an eye on this in the future. There are some other changes in the next release around this area and although my test environment now runs the Italian locale you're more likely to spot any regressional problems than I might.