MediaMonkey 5 plugin for Rainmeter

[TIV73]

Alright, the good news is that deserialization with the track object you provided works perfectly, and the application throws no errors. The bad news is that deserialization with the track object you provided works perfectly, and the application throws no errors.

Which means that I cannot reproduce your error, even using the same track object. The application fails when parsing track timestamps like the last played date, date added to library, etc.. Since these values are all valid and parse fine locally for me it could be that the problem is related to globalization settings. Which basically means that an application can behave slightly different depending on where you are, because it respects settings provided by your operating system in regard to localization. Stuff like first day of the week, date and time formatting, decimal symbols, unicode settings etc.

Nowadays a lot of this stuff works fine without having to care about it, but there are always edge cases, and finding and fixing them can be tricky (as demonstrated in the last couple days).

To be on the same page - even though a globalization issue seems plausible, it's just a possibility. It really seems like there's some environmental factor, but that could be anything, and I'm honestly not sure how I would troubleshoot for that without being able to reproduce in on my end, even with the same data. I have one more debug build to try out with some updated error handling, but if that doesn't work I'm kind of running out of ideas. Could you see what the new version works better than the old one and/or post its output again?

[Kodijack]

Thanks for all the troubles man
I tried the new one too and you seem to have been on the right path:

the exceptions were thrown at deserialization of lastTimePlayed, DateAdded, fileModified, trackModified.

"fileModified":"44941.001321354"
"trackModified":"44941.001321354"
"lastTimePlayed":"44936.855604294"
"dateAdded":"44904.0719704977"

all else seem to work fine (if you want i can upload the log again?)

As for my locale:
English [Germany]
Means german for date-format & co , and language is english.

Maybe it's just the swapped month/day (assuming you're american)?

[TIV73]

Not quite, I live in Austria. But I'm pretty sure it's not related to regional date formatting anyway since the value that's being deserialized is not a date but a string like '44941.001321354' which is not exactly a common way to write dates in any region.

But I found something else that could cause the problem. Could you try the this build?

[Kodijack]

Austria. I couldn't have been more off with USA than this
Thought it was maybe some unix-timestamp or something which got scrambled up in conversion.

Your new upload doesn't show any errors anymore and reports (in the end):

Current Track:
Title:Phantasmal Eye of Dreams
Artist:Battle Dagorath
Rating:60
Position:00:00:17.4020000
Progress:2 %
Player state:Playing

Is that good news?

[TIV73]

It is. It means that the error you encountered has been fixed in that latest version of the library. Which means that I'll look into publishig a new version of the library and rainmeter plugin.

I had to make some changes in how data is handled by the library which could cause some issues for the plugin, so I need to clean everything up and do some testing to make sure the new version doesn't break rainmeter. I'll post an update in this thread when the new version is available, but depending on how well everything goes that could take anywhere between a couple of days to a few weeks.

[Kodijack]

Excellent! And no worries, I'm grateful you'll do it at all. At least we found the culprit!
And many thanks again!

[Peke]

value that's being deserialized is not a date but a string like '44941.001321354' which is not exactly a common way to write dates in any region.

Just as a note it is Normal UTC date time var representing time passed from 30.12.1899 12:00 AM and can be further formatted with API like https://www.mediamonkey.com/docs/api/cl ... tTimestamp if needed.

https://learn.microsoft.com/en-us/cpp/a ... w=msvc-170

[TIV73]

I'm not sure I understand your suggestion. What I'm basically doing is running app.player.getCurrentTrack(), take the json that's returned, and deserialize it into a .net object. All the dates in that json are returned as ole automation timestamps, so I run them through a converter to translate those numerical values to .net datetime objects and I'm done.

Wouldn't it introduce massive overhead (relatively speaking) and complexity if I were to add additional calls to format these timestamps instead of taking the values as they are? Not only would that be multiple js calls to get the track object and convert all dates, I would also need to juggle multiple objects in js and then do the same in reverse in .net. And on top of that I still need to convert the strings to datetime objects.

[Peke]

I'm not sure I understand your suggestion.

I was just explaining the format you get and source format. Handling it completely up to you. You are right it is not needed you are doing it the fastest way anyway.

[TIV73]

Ah alright, gotcha. I thought there's something I'm missing. Thanks for the note!

[Peke]

Ah alright, gotcha. I thought there's something I'm missing. Thanks for the note!

I constantly forget that now most of things are already handled automatically using premade functions types, libs. Only downside is that those bloat apps. I remember that for a high school contest I had made 256bytes mouse pic editor in 16 colors at res 320x240 where you get white background, left mouse paints pixel and right one changed color of single pixel mouse pointer

Keep up the good work.

[Kodijack]

downside is that those bloat apps. I remember that for a high school contest I had made 256bytes mouse pic editor

That reminded me of my high school contest, it was about who made the tiniest yet most fully featured text-editor. á la Linuxs' Nano. And I did. It was much simpler times. Nowadays a simple text-editor needs 91823123 libraries to just boot up
And the WWW shifted from 99,9% pure information to 2% information, 58% libraries needed to display the 2% information, and 40% ads/tracking...

[Peke]

Hi,

It was much simpler times.

ohhhhh, yes. As a winner of high school contest I got access to internet (as part of University intranet) from 1992 (had my first modem [1200] in 1989 at price similar to nVidia GeForce RTX 4090 today), the things were much more fun those times when you need to optimize and whole app on one these below.

[Kodijack]

ohhhhh, yes. As a winner of high school contest I got access to internet (as part of University intranet) from 1992 (had my first modem [1200] in 1989 at price similar to nVidia GeForce RTX 4090 today), the things were much more fun those times when you need to optimize and whole app on one these below.

Ahhh 3M-disks. Sweeet.
Oh I remember. You were even there before me. My first was a 28.8k for around 200$ (Why was it THAT expensive in Serbia?!). And then many years of BBS-love started.
For my first Internet I had to visit the neighbor-town and sign a contract in person and join some club lol.
Simpler. Yes. We had to quench everything to optimum OR ELSE
Around that time I also did my own MediaMonkey-music-library-manager (because there simply was none at all) and even released it. Then I tried some "SongsDB" and ditched mine....Now we're here, talking. And it's MM5. Man I'm old

[Peke]

Hi,
Yeah 8" Floppy disk that contained 26 Sectors of 128bytes per side totaling 3.3Kbytes LOL.

I guess we can talk like this for hours. Maybe I overpriced a bit with 4090, but at time Serbia was in civil war in 90's and when you have paycheck of 20 then 200 sounded like 2k. Also considering inflation https://www.officialdata.org/us/inflati ... amount=200

FYI 28.8k came much later in late 1994.

Ah, BBS (Grand grand father of Social networking) and was Sysop of one of them 1993-1999 till NATO bombing of Serbia.

@TIV73 Sorry for hijacking topic, I'll stop.