Priority queueing based on queue score
Priority queueing based on queue score
I suggest an interesting variant of priority queuing,
based on both the priority and age simulataneously,
similar to one used in some P2P software with request queue management.
Podcast channels would be assigned priorities as until now.
But the queue position would NOT be like
sorted by priority, than by release_age.
It would be sorted by queuescore = prioritymultiplier * releaseage
where prioritymultiplier = 2^(priority -1)
So 8(exactly) days old episode with priority 1 would have the same queue score and as
4(exactly) days old episode with priority 2, or
2 days old episode with priority 3, or
24 hours old episode with priority 4, or
12 hours old episode with priority 5, or
Hey, I implemented a similar feature in the latest Beta of the app as a test.
Can you please join the Beta on the app Play Store page and then download the latest update
Then please go into Settings/Playlist and enable ‘Smart priority sorting’
Please let me know how this works for you so I can know if this makes sense to have this in the next version of the app
FYI this takes into account priority and episode release date
Using for some time, working great. I do not use anything else since implemented in Beta. Would be working great if there was implemented dragging down the playlist for the playlist queue order refresh.
Hmm, Hmm.. It would help if I knew queue scoring schema. It behaves ... strange.
To describe my scenario:
I have currently about 400 item queue.
I use low priority, where is about 360-380 items, up to 3 weeks old.
I use medium priority for topical channels of high interest, typically 15-25 items, usually 1-3 days old.
I use high priority for news and commentaries channels, usually max 1 day old, typically 5-15 items.
I have set the smart queue priority sorting as adviced.
I have played with values of priorities
I set 1 for normal,
4-256 for higher
8-32767 for top one.
I have not still managed all the rules of the unpredictable queue behaviour.
It puts usually few or more of top or medium items,
then there is a huge block of 100-200 low priority items with 7-10 days time span, than another short block of high/medium priorities. Some of them are even in last 20 items, being 2 - 23 hours old.
It serves almost like anti-prioritization.
And now, I do not know how, it decided to ignore my sorting oldest first and lists newest first, I had to turn smart queueing off/on to fix it.
I am still not sure if some dynamic resorting is in place, or if it happens only by adding new items or on demand.
I usually end with many top/medium items pushed deep down ( what is inferior to usual high->low + old->new sorting, with or without alternation).
Or, I end with near all too/medium items on the top, what is like usual high->low + old->new sorting. But still some non low items may laybon the very bottom of the queue.
I think it may not be ready for release.
P.S.: If it happens the publication date of all top/medium items is today, it looks they all prefer to sit at the queue bottom with the other today items, instead of at least some being on the top.
Joined to beta program, but refresh of updated has not revealed the beta yet. When arrives, I am going to do thorough testing. Thanks for the update.
Hm, download age is not my preferred criteria, I prefer priority + release age.
There's a common, simpler algorithm that's just: (Priority + DaysSinceDownloaded).
It's really nice because it's stable. A fully-downloaded playlist of episodes will stay sorted in the same order even if you ignore it for a day. And that makes perfect intuitive sense: if they all got one day older, then their priorities compared to each other should stay the same. Then if you download a new episode, it just gets inserted somewhere into that sorted list based on its (priority+age) also, with no reshuffling.
By contrast, the ((2^(priority-1))*releaseage) algorithm would cause the playlist to reshuffle in weird and counterintuitive ways.
P.P.S.:Perhaps better to evaluate the queue scores not at the end, but at the beginning of current episode playing. In such a case the queue would be pseudo-static during the play, allowing the manual user intervention - like e.g. move as the next played episode or move to the top etc.
P.S.: As the queue ranking would be dynamic, there would be evaluated at the end of the current episode playing, what episode should be the next one.