Author Topic: Wifi android device synching  (Read 310691 times)

Freddy Barker

  • Sr. Member
  • ****
  • Posts: 751
  • 🎧 MB 3.4.7628P
Got another one with wrong date. Played today.
https://i.ibb.co/3rxVQcp/002.jpg

That is odd!?
That is the date that computer chip clocks start from when calculating the current date and time.
Can't see it being an issue with MB as it must get that info from your PC's system clock...

However, from you previous post

<LastPlayed>1568399940373</LastPlayed>.

...is the number of seconds since 1st Jan 1970 and, when you played that track.

Regards: Freddy
Last Edit: September 17, 2019, 01:14:28 PM by Freddy Barker

Babydoll32

  • Full Member
  • ***
  • Posts: 139
Got another one with wrong date. Played today.
https://i.ibb.co/3rxVQcp/002.jpg

That is the date that computer chip clocks start from when calculating the current date and time.
Can't see it being an issue with MB as it must get that info from your PC's system clock...


Thanks for answer. Any Idea how to fix it?

Freddy Barker

  • Sr. Member
  • ****
  • Posts: 751
  • 🎧 MB 3.4.7628P
Thanks for answer. Any Idea how to fix it?

Probably best to see if it's something Steven needs to look at later, as may want to do test(s).
Freddy

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
The number is 1000 x too large ie. it appears to be milliseconds rather than seconds. I suggest you check with the GoneMad developer if he has changed anything intentionally

SkyZippr

  • Jr. Member
  • **
  • Posts: 121
My GoneMad is working fine. Which version are you using?

Babydoll32

  • Full Member
  • ***
  • Posts: 139
My GoneMad is working fine. Which version are you using?

Mine works also fine, but from time to time, some songs have wrong last played date.
I'm using GoneMad 2.2.21.

Babydoll32

  • Full Member
  • ***
  • Posts: 139
The number is 1000 x too large ie. it appears to be milliseconds rather than seconds. I suggest you check with the GoneMad developer if he has changed anything intentionally

Hi Steven.
Did it and get this answer by GoneMad dev.

Quote
That date is the equivalent to 0 in "computer time" which is the default value in gmmp for songs not ever played. Musicbee should be ignoring 0s for last played when syncing

edit: looking further, when updating the last played time its using the current time

values.put(DBConstants.TRACK_LAST_PLAYED, new Date().getTime());
The other call that updates the field in the database wont update it back to 0 either:

if (lastPlayed != 0)
    values.put(DBConstants.TRACK_LAST_PLAYED, lastPlayed);
So the only way it could be 0 in the database would be if was never played. I dont speak what appears to be german, so i dont know all the fields in that screenshot.. but im guessing the column with all the 1s is playcount? I guess theoretically the playcount could have been synced back to gmmp with a 0 last played, so the restore updated the playcount but not the last played.

If you can find a way to reproduce this i can certainly look into it more

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
what does any of this have to do with:
The number is 1000 x too large ie. it appears to be milliseconds rather than seconds. I suggest you check with the GoneMad developer if he has changed anything intentionally
the example you provided from the GoneMad stats.xml <LastPlayed>1568399940373</LastPlayed> must be milliseconds and not seconds ie. if its divided by 1000 a sensible date is derived. Normally the GoneMad values are expressed as seconds. Because the value is in milliseconds it is overflowing when converted to a windows date/time so you get stupid values for the date
Last Edit: September 18, 2019, 06:57:24 PM by Steven

Babydoll32

  • Full Member
  • ***
  • Posts: 139
Normally the GoneMad values are expressed as seconds. Because the value is in milliseconds it is overflowing when converted to a windows date/time so you get stupid values for the date

That's what GoneMad dev wrote Back:
Quote
correct, gmmp stores anything time related in milliseconds since that works best with the java Date class:

https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#Date-long-

https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#setTime-long-

https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#getTime--

edit: lastPlayed, dateAdded, and dateUpdated(gmmp 3.0 alpha) are all in milliseconds. I think thats the only time related fields that backup/restore deal with
Last Edit: September 20, 2019, 08:10:16 AM by Babydoll32

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
the point is usually the timestamps are expressed as seconds from 1970 but in some cases they are being expressed as milliseconds from 1970

Babydoll32

  • Full Member
  • ***
  • Posts: 139
the point is usually the timestamps are expressed as seconds from 1970 but in some cases they are being expressed as milliseconds from 1970

Yes. Seems so. But not a big thing, like I said, as long as playcount syncs correctly. Thanks for good work!

vpsaxman

  • Full Member
  • ***
  • Posts: 197
I'm getting some "Files not matched in MusicBee. Playcount not changed" errors when I try sync them from within the Android app recently.


- MusicBee version 3.3.7165
- MusicBee Wifi Sync version 0.9
- Android 10 on a Pixel 3
- Poweramp version 3 Build 841

I've tried deleting the Android app and re-synching to no avail. How can I further investigate what's causing the issue? Thanks!
Last Edit: September 25, 2019, 08:26:19 AM by vpsaxman

splatt

  • Jr. Member
  • **
  • Posts: 20
I'm not sure if it's too late to say this, or if this is still the right place but I know that there's a number of people using an Android app called Black Player (and Black Player Ex) by FifthSource that use musicbee on their computers -- enough that the developers have been trying to make changes to the playlist formats to make syncing easier for musicbee.

Also, BlackPlayer has a free version, whereas the current options seem to only have free trials. (Not trying to say we shouldn't pay for apps, but it seemed like it might be something to consider).

Phil Lloyd

  • Newbie
  • *
  • Posts: 2
I'm getting some "Files not matched in MusicBee. Playcount not changed" errors when I try sync them from within the Android app recently.


- MusicBee version 3.3.7165
- MusicBee Wifi Sync version 0.9
- Android 10 on a Pixel 3
- Poweramp version 3 Build 841

I've tried deleting the Android app and re-synching to no avail. How can I further investigate what's causing the issue? Thanks!

I got the error warnings, but the files are there ok - have not checked the actual playcounts.

- MusicBee version 3.3.7149P (older)
- MusicBee Wifi Sync version 0.9 (same)
- Android 8.0.0 on Moto Z2 Play  (older)
- PowerAmp 3 Version 3 build 853 (newer)

But if I just sync my playlists I get no error.
Playlists are found and play in PowerAmp fine, too.

psychoadept

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 10691
I'm getting some "Files not matched in MusicBee. Playcount not changed" errors when I try sync them from within the Android app recently.

I'm getting this message, too, and I don't think the file paths have changed in MusicBee or anything like that. It's ~30 tracks out of probably <300 that have played since my last sync so it's a pretty big percentage. Maybe we could get a list of tracks that didn't sync correctly that we can save as a text file at the end?
MusicBee Wiki
Use & improve MusicBee's documentation!

Latest beta patch (3.5)
(Unzip and overwrite existing program files)