Author Topic: Auto-Playlist sorting & static m3u playlist export - "<SortBy Field" oddity ?  (Read 2122 times)

alec.tron

  • Hero Member
  • *****
  • Posts: 735
Heya,
so after dozens of Auto-Playlists having gotten messed up column display and sorting ( https://getmusicbee.com/forum/index.php?topic=23561.0 ), this now also seems to affect the exported static m3u playlists for me as well.

Can anyone shed some light (might be only Steven would know) and explain what the "<SortBy Field" in an .xautopf of Musicbee does relate to exactly ?
Are these <SortBy Field codes documented somewhere ?
Are they relative to the columns of the playlist or absolute/global field values ?
I could not find them on the forum and neither in the twiki,


As to the issue - I have now gone through all Auto-Playlists and loaded my custom default column view for each where it wasn't on the same column layout (10-20 or so of 117 Files), and sorted them 'by Rating value' as well for all where this wasn't the case as well. So all should be good now as this was the state they were in before (the 3.2 update I believe) and which I need them to be in for static playlist export (for this trick to work:
https://getmusicbee.com/forum/index.php?topic=20764.msg122920
to write out a iTunes xml where all Auto-Playlists have a 'rating sorted' static playlist equivalent. And all non-auto-playlist based ones remain in their 'natural sorting' way...).
Now, even with all Auto-Playlists fixed/aligned by hand, my resulting static playlists of the Auto-Playlists that I need to generate the iTunes xml from, have now taken on all sorts of sorting which I am trying to a) understand, and b) fix...

So, I have switched all auto-Playlists to rating based sorting, and most state:
Code
<SortBy Field="75" Order="Descending" />

Most of the culprits that produce incorrectly sorted static playlists do have other Sortby Field values, such as:
Code
<SortBy Field="2" Order="Ascending" />
Code
<SortBy Field="47" Order="Ascending" />


Now to the real oddity with this - I've double checked the ones in MB that do NOT have:
Code
<SortBy Field="75" Order="Descending" />
in their xautopf file, and even they are sorted 'By Rating' inside of MB as they should (and they even have the same column fields & order - I thought IF they are column relative to the playlists shown columns... this could explain it... but no, based on the breadcrumbs)... so this does not quite compute.

Any explanation here would be much appreciated.
Also - in case anyone else sees something similar, this feels somewhat buggy to me, but have yet no idea if/how to reproduce these.

Churs.
c.
Last Edit: December 14, 2017, 07:43:00 AM by alec.tron

alec.tron

  • Hero Member
  • *****
  • Posts: 735
Looks like going to MB, and switching all Auto-Playlist that have not had
Code
<SortBy Field="75" Order="Descending" />
but a different value in their .xautopf file, to:
Sort by Rating column in MB (which was already switched on on all of them in MB - indicated by the grey downwards triangle... which is the slightly worrying bit...), which inverts them to 'Ascending', then sorting yet again By Rating to get it to stay on 'Descending' does indeed force the .xautopf to be rewritten, this time seemingly correctly with
Code
<SortBy Field="75" Order="Descending" />
and the resulting m3u file then sorts by that as well as expected.

Any idea why and / or how a good 10-20% of my Auto-Playlist have gotten into this messed up state (of MB & xautopf stating different things from how it seems) all of a sudden after using this approach for a good year (3.2 update maybe) ?

Cheers.
c.

ps, some details, found:
4 x
<SortBy Field="2" Order="Ascending" />

3 x
<SortBy Field="47" Order="Ascending" />

and 1 x
<SortBy Field="99" Order="Ascending" />


Yet all of them did show in MB that they were sorted by 'Rating' already, so should have been
<SortBy Field="75" Order="Ascending" />
Last Edit: December 14, 2017, 08:15:54 AM by alec.tron

Steven

  • Administrator
  • Hero Member
  • *****
  • Posts: 33267
"SortBy" and "DefinedSort" are the persisted sorting that has been applied to the main panel at the time the auto-playlist is active in the main panel. You can change the sorting and hence stored values simply by changing the main panel sorting the usual way.

alec.tron

  • Hero Member
  • *****
  • Posts: 735
For me, and using this regularly, this is the crux that makes this down right faulty & very frustrating:
"SortBy" and "DefinedSort" are the persisted sorting that has been applied to the main panel at the time the auto-playlist is active in the main panel.

Let me explain.
I use a goven layout view.
I create a smart-playlist. This gets sorted a specific a way then, and sets its' persistent sorting relative to the layouts' field.
Then a few weeks go by, I adjust layouts & sorting in other playlists, then set it all back pre-exporrt as I needit to, in order for the sorting to arrive in the m3us as I need it to, then export all as static m3u playlists, and suddenly the previously created playlists set to sort by 'rating', does not sort by rating anymore when exported to m3u.
So yes - when one given palylist was created this was probably true:
<SortBy Field="2" Order="Ascending" />
to be 'By Rating'
But, after some modifications, the same sorting method in combination to the latest layout made sorting 'By Rating' was then the following:
<SortBy Field="47" Order="Ascending" />
making the previous not true at the same time.
And again a few days/weeks later, suddenly it's.
<SortBy Field="99" Order="Ascending" />
throwing a spanner into the validity of the previous 2...

So yes, I can:
change the sorting and hence stored values simply by changing the main panel sorting the usual way.
But when there's 100s of playlists, this is quite time consuming & has a fair bit of frustrations build in, due to the mutating relation of layout & soting field over time, as it requires me to click every single auto playlist by hand pre-export to make sure they all update their sorting to the latest applied layout - and as you can see on the crash dump I posted in bugs, doing this quickly via arrow keys not only misses some -and doesn't set the sorting/layout relation correctly when done quicjkly via arrow keys, but also can cause MB to crash fully.

I do hope this makes sense, as trying to fix wrongly-sorted playlists again and again, coming out of these ever mutating co-relations, is a lot like poking around in the dark with a long stick, trying to hit a light switch on the far end of the wall...

Churs.
c.
Last Edit: April 07, 2018, 06:10:58 AM by alec.tron

Steven

  • Administrator
  • Hero Member
  • *****
  • Posts: 33267
So you are saying you didnt touch the affected auto-playlist in any way (eg. remove columns) ie. you were just editing other playlists?
Is the affected auto-playlist using a custom view (ie. a view you created via the "Custom Views" menu)?
Did the affected auto-playlist have dependencies on the playlists you did edit?
Lastly do you have the affected auto-playlist open in another tab while you are editing other playlists in another tab?

in case it sheds light on anything, 47 is the "Custom2" tag and 99 is the "Custom9" tag
Last Edit: April 07, 2018, 11:25:42 AM by Steven

alec.tron

  • Hero Member
  • *****
  • Posts: 735
Interesting...  "47 is the "Custom2" tag and 99 is the "Custom9" tag" I indeed use for tags that I sort by oaccasionally & temporarily - but, before exporting smart-playlists to static ones, I always actively switch sorting to be Rating based, and this is the annoying bit, that this switch, despite being shown as the active sorting in MB does not export to the xpf reliably for me as every time there's some that get missed, which I only notice when I double check the resulting static playlists. Which is a fair bit of work with +100 smart playlists (and there's more to come...).

As for the questions:
- yes, I am using custom views for all, and I mostly use track views everywhere, bar 2 dedicated album cover /album-track view tabs of the whole library
- no dependencies - these playlists in question purely query / are set to update based on metadata / file tags only
- no other (playlist) tabs, apart from the 2 tabs mentioned above, I only have 3 other tabs. 1 for inbox. 1 for playlists. 1 for the main music library in tracks view.

Since this is so hard to track down, this was the reason I posted the wishlist thread about having icons in the Playlist Manager which might give a better handle to visualize locale/discrepant playlist settings rather than relying on hand-checking the output files. Just a thought though.

Cheers.
c.

Steven

  • Administrator
  • Hero Member
  • *****
  • Posts: 33267
if you are using a custom view in the affected auto-playlist and that custom view is also used in the playlist you re-sort then that will also impact the auto-playlist ie. any changes to a custom view (sorting, fields) will affect all places the view is used

alec.tron

  • Hero Member
  • *****
  • Posts: 735
Hm.
To clarify as there's many angles how this could be interpreted differently within the MB context:
- I do use tracks view for all playlist
- (Through Tracks > Custom Views > x ) I have set all playlists globally to use the same custom view (as default[?] )
- all playlists are set up locally/internally to  'Display using view: "Default" [i.e. the custom view above]
This all works, so when I switch a  column or sorting in one of them, all switch their tracks/column layout and/or sorting in MB respectively.

But, there is some that still regularly not adhere to the set sorting and export with some other sorting that is not set explicitely anywhere, so my only handle is this:
- change the sorting to what I am after for sorting in the resulting static playlists, i.e. by Rating
- export static playlists
- shut MB down
- remove SmartPlaylist folder from MB library
- copy SmartPlaylist_Static folder into the library
- load up MB
- now I (need to) go through all exported playlists to vicually check they have indeed received the same sorting
- write down the names of the ones that didn't as theres always 5-10
- shut MB down
- revert smart playlist folder swap - i.e. delete the static ones, move back the dynamic ones, restart MB
- now click each of the smart playlists that exported with unwanted sorting
- click Rating column once - which then changes the sorting to be ascending now (as it is always showing descending here as intended for the export) - click the rating column again to explivcitely set it to descending Rating sorting for this specific playlist
- go to next smart playlists that didn't export with the intended sorting
- rinse & repeat until all are fixed
- do the export again
- swap the smart for static playlists again (as the iTunes export I need to do after all of this has issues with playlists of the same name)
- double check all static playlists
- now I'm good to write the xml I am after, and where I need the sorting

Churs.
c.
Last Edit: April 07, 2018, 10:40:56 PM by alec.tron

Steven

  • Administrator
  • Hero Member
  • *****
  • Posts: 33267
An auto-playlist and a flagged static playlist has its own set of fields when using the standard track details view but by using a custom view, directly or in your case indirectly because you have set the playlist category default (as distinct from music, audiobooks, inbox, etc), any field or sorting change affects every playlist ie. you are updating the custom view, not the specific playlist (although MB does also write the change to the current active playlist).
If you want to keep using that approach but preserve the fields and sorting for specific auto-playlists, then you will need to create another custom view and directly assign the auto-playlist to use that

alec.tron

  • Hero Member
  • *****
  • Posts: 735
Yea, this is actually the behaviour I am after: "any field or sorting change affects every playlist" [there is no case where I ever want '...preserve...sorting for specific auto-playlists' - I always want to switch globally / for all smart-playlists * !] - and thereby, when I switch to a given sorting (i.e. to sort all by Rating), all auto-playlists should export as such to static copies as I understand it from your last description.
But, exactly that is not reliable as is as and I regularly have exported static playlists that have not received the correct sorting.

As said, in my experience a playlists needs to be active to save it's "<SortBy Field" correctly & reliably (but there is a a complex co-relation between when the playlist was sorted by somethign else last, and what columns were shown at the time...)- if there is any ways for me to make this more reliable, please let me know, as this costs a good 1-2 hrs every few days/weeks to get all Auto-Playlists to correctly export into a static copy of itself.

Cheers.
c.


ps. * - with the exception of non-auto-playlists / the ones that are already static and have a (inherent) 'natural sorting' defined obviously.
Last Edit: April 08, 2018, 12:03:54 PM by alec.tron

Steven

  • Administrator
  • Hero Member
  • *****
  • Posts: 33267
Export for static playlists will be whatever the natural order of the playlist at the time you change it.
Auto-playlists, i can see scope for inconsistencies because MB is using the sort value saved in the playlist which can become inconsistent with the view if you are changing the view sorting back and forth when another playlist is active.
I am prepared to enhance it to look up and get the current sorting value from the view but that will only work if the auto-playlist is explicitly set to use the view

edit:
actually thats already the case, so just explicitly set the auto-playlist view to the appropriate custom view
Last Edit: April 08, 2018, 02:33:24 PM by Steven

alec.tron

  • Hero Member
  • *****
  • Posts: 735
Thanks for the explanations Steven!

Before I go through and change 100+ playlists' view attributes to explicitly use a saved custom view - these are live/connected to the custom view (so IF I change the custom view file on disc, this will propagate to all auto-playlists that are set to use this custom view), correct ?

Cheers.
c.