View Issue Details

IDProjectCategoryView StatusLast Update
0014384MMASynchronizationpublic2018-03-13 16:50
Reporterrusty Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version1.3.1 
Target Version1.3.2Fixed in Version1.3.2 
Summary0014384: Some Podcasts sync/display in reverse order
DescriptionIn MMW, there are 2 types of podcasts:
1) Episodic podcasts (e.g. 'Serial') that are designed to be played oldest to newest. These are configured in MMW to 'download oldest episodes first' so that the user can play them in chronological order.
2) Podcasts in which the more recent content is more valuable (e.g. 'CNN', 'Stuff you should know'), that users play Newest to oldest (sometimes skipping older episodes entirely). These are configured in MMW to 'download recent epeisodes first' so that the user can play them in reverse chronological order

When MMA/MMW sync, it seems that podcast episodes are always downloaded Newest to Oldest, which means that Episodic Podcasts (case (1) above) can't be easily played in order (since they're listed most recent to oldest in the Podcasts views).

Can this be rectified by having MM 'know' to sync tracks in a specific order depending on the type of podcast?

Note: in MMA 2.0 this issue will be ameliorated by the fact that users will be able to resort tracks by date (asc/desc), however, it would still be preferable if this could have a systemic fix.
TagsNo tags attached.
Fixed in build800

Activities

Ludek

2017-09-12 14:21

developer   ~0048714

Assigned to me to add the "order" info for the podcasts.

rusty

2017-09-12 14:32

administrator   ~0048716

Last edited: 2017-09-12 14:36

Ludek pointed out that MMW already includes sync settings allowing the user to sync the 'x most recent' or 'x oldest' episodes/unplayed episodes. Unfortunately most users don't bother with the oldest/recent settings since they are global (they can't be set per podcast).

It would be much easier if sync operations just synced an 'order' attribute taken from the Podcast settings. i.e.
recent episodes first --implies--> default sort newest to oldest
oldest episodes first --implies--> default sort oldest to newest
all episodes / no episodes --implies--> default sort newest to oldest

This could also eliminate the need for any newest/oldest config in the sync settings. i.e. Once we sync an 'order' attribute, it would probably make sense to change the sync settings to:
Sync: __[All], 1, 2, 3, 5, 10__ __[episodes], unplayed episodes__
i.e. get rid of the order settings, since sync order would be determined based on the podcast settings.

rusty

2017-10-31 20:23

administrator   ~0049093

Last edited: 2017-10-31 20:29

Considering:
a) the comments at ~48838 (that users are likely to want to sort podcasts manually because the download order may not always match the sort order)
b) that episodic playlists are _designed_ to be played in order whereas others are only optionally played in order (see feedback at http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=88676 )
c) that for non-episodic podcasts, the user often only wants to play the latest track and does so by limiting the number of episodes synced to only the most recent

it would therefore be preferable for MMA to, by default, display podcasts from oldest to newest, instead of newest to oldest.

Martin, Marek, would it be trivial to implement this for 1.3.2 ? Then at a later date we can decide whether additional functionality is needed.

martin

2017-11-08 12:39

developer   ~0049128

Last edited: 2017-11-09 21:18

So default order changed for podcasts to order it from oldest to newest in build 1.3.1.737

peke

2017-11-10 00:59

developer   ~0049142

Verified 737

rusty

2017-11-15 16:24

administrator   ~0049183

I'd assumed that although the dates were equal, the timestamps weren't so a sort by date and timestamp would work (oldest to newest for both).

Alternatively, sort by date and title should also work (oldest to newest for date, alphanumeric sort for title).

martin

2017-11-30 16:19

developer   ~0049318

Last edited: 2018-03-13 16:50

Fixed in build 1.3.2.800