Ticket #8653 submitted along with MMA debug log 6TKI9EWIR

I thought I had the steps to replicate my issue figured out in my previous post but I was wrong...I think I have it figured out now. I have three randomized playlists where each is a combination of 4 auto-playlists that are also randomized. Playlist 1 = Playlist A + Playlist B Playlist 2 = Playlist ...

I've been away for a couple of weeks but can confirm that MMW 3074 performs as expected and subsequent betas show the inconsistency for me. Here is a screenshot of MMW 3074 https://imgur.com/Mf8r86T and a screenshot of MMW 3082 https://imgur.com/XdbF7pG As you can see the playlist order in both is ...

The same things happens.

One critical piece I forgot to mention is that Playlist 1 and Playlist 2 are not regular playlists, but auto playlists also sorted radomly. Playlist 1 is songs rated 4 or higher not played in x days, and playlist 2 is unrated songs never played.

I have some playlists where the playlist is Search - entire library Match - any - Playlist is Playlist 1; Playlist 2 No limit Sort by - Random on MMW this works just fine Since Beta 3078, upon syncing with MMA the resulting playlist order is Playlist 1 sorted randomly followed by Playlist 2 sorted ...

Log sent with ID of 97M4Q3ESXQ

After playing once in MMA the play count is at 2
Sync with MMW, play count is 3

MMW is build 2827 (portable), wi-fi sync.

Phone is Pixel 7 Pro
Build UQ1A.231205.015, issue started before the latest update

I have a playlist of songs that are unrated, and never played sync'd from MMW to MMA.

On MMA build 2.0.0.1157 if the song is played from that playlist, upon sync with MMW the play counter is set to 3, instead of the expected value of 1.

I have one auto-playlist on my device that is a subset ( 3 GB max) of songs rated 5*. Before starting the synch there were 193 tracks on the device Synch started and MMA prompted to delete 161 tracks, all were selected and removed from device There were 175 tracks to download. After the 175 tracks ...

Well maybe version 4.5.0 wasn't ready for prime time..... Another update ready for install now that fixes a few bugs, some new some old. fix bug that could result in the script waiting for a very long time to proceed with searches if the user switched from MB to Discogs. There was no way to end the ...

Robb Thanks for the kind words. Discogs does limit the number of API requests. The script limited the requests to 3/second but Discogs changed the limit shortly after I implemented that rate to 60/minute for authorized requests and 25/minute for unauthorized requests. As MM5 was in alpha I had not ...

I get the same error, screenshot

I'm now getting a new error every few songs or so: "Error #13 - Microsoft VBScript runtime error Type mismatch: 'ojsonVersions(...)' File "C:\etcetc\EarliestDate.vbs", Line: 1005, Column: 8" Running Mediamonkey 4.1.15.1828 Pro on Windows 10 This is most likely due to the API rate limit change at ...

It appears that in the MusicBrainz transition to HTTPS, the domain www.musicbrainz.org no longer points to musicbrainz.org.

For a quick fix try editing lines 798 and 1479 from www.musicbrainz.org to simply musicbrainz.org.

Wondering if anyone else is suddenly receiving a Security Warning when doing a search with MusicBrainz. Full message: This page is accessing information that is not under its control This poses a security risk. Do you want to continue? The message pops up for every song, so when your cycling ...