Next up jumps to first item after playing from other position

[Gilgamesh_48 944]

I know the behavior of jumping to the first position after playing an item from next up is what the developer of the Android app thinks is correct BUT it is only correct for those that play the episodes from the same show in order. I do NOT do that in the normal course of playing my TV  shows. I like to play episodes from several different shows in a rotation.

 

ex: I might want to play a episode of Star Trek TNG followed by Star Trek DS9 followed by Star Trek Voyager and then repeat those three over and over for several episodes. To do that with the current behavior of next up I must press the right arrow several times after each playback to get to where I would like to be after an episode ends.

 

I understand that what I want might not be what many people want but I know several people that do watch the way I do.

 

I think it should be a CHOICE!!!

 

I would like to use my Fire Stick for TV playback but the clumsiness of this operation style make it too inconvenient for me. 

 

Please allow choice in this next up behavior!

[ebr 14937]

An option for something like this is not likely.  You'd need a page of text and a video to properly convey to a user what the option does .

 

For the record, I don't know that there is a "right" answer here as you can make an argument either way depending on exactly what operation has occurred.  In your example, you come back to the same series you just watched so that does seem to be the most intuitive result.

 

But as I've stated before, this is really just default behavior of the platform when a list is re-loaded and trying to make it behave differently isn't something that we've attempted at this point because there really isn't a clear "right" answer in all cases.

[Gilgamesh_48 944]

An option for something like this is not likely.  You'd need a page of text and a video to properly convey to a user what the option does .

 

For the record, I don't know that there is a "right" answer here as you can make an argument either way depending on exactly what operation has occurred.  In your example, you come back to the same series you just watched so that does seem to be the most intuitive result.

 

But as I've stated before, this is really just default behavior of the platform when a list is re-loaded and trying to make it behave differently isn't something that we've attempted at this point because there really isn't a clear "right" answer in all cases.

 

But it does. or at least did, behave differently on the Shield and they are both Android. On the Shield the problem is that the position jumps one place to the left instead of staying at the same position or returning to the beginning.

 

I fail to believe that the Plex programmers are better that you guys but in the Plex Android app the position in "On Deck" (which is what they call next up) does not change after playback. That is if you are at position 10 and play the episode there that show's next episode moves to position one and all the other shows move up one spot and the selected item remains at position 10.

 

As you said there can be arguments made for both jumping to position one and remaining where you are after playback and because of that there should be choice and the fact that you do the first and Plex does the second make me believe that adding choice should not be particularly hard.

 

This behavior is keeping me from using any Android device for my main viewing. I know that is not particularly important to you BUT it is very important to me.

 

BTW: I have several friends that have started using Emby (Well I guess four could be called several) and they all, except one, want to remain at the same place after playback. That is not a large sample but it is all the sample I have.

 

But it is your app, not mine, so I will use it as you write it. I have zero desire to return to Plex and this does not make that return any more attractive. Using Plex is just too much like a certain scene from "Marathon Man" where the question is asked: "Is it safe?"

[CBers 6771]

For the record, I don't know that there is a "right" answer here as you can make an argument either way depending on exactly what operation has occurred. In your example, you come back to the same series you just watched so that does seem to be the most intuitive result.

 

The "right" answer is to work out how to stay in the last position rather than jumping to position 1, then make it an option for the user to decide how to use it.

 

This has been brought multiple times and still no movement in the "right" direction.

[ebr 14937]

But it does. or at least did, behave differently on the Shield and they are both Android. On the Shield the problem is that the position jumps one place to the left instead of staying at the same position or returning to the beginning.

 

I've never seen that behavior in this app on any device.

 

At some point, this issue will make it to the top of the list of little oddities to look at.  It just hasn't yet.

[Gilgamesh_48 944]

I've never seen that behavior in this app on any device.

 

At some point, this issue will make it to the top of the list of little oddities to look at.  It just hasn't yet.

 

It had been a while, actually quite a while, since I had tried Emby on my Shield, I usually use Roku or Fire, and I decided to check the behavior there just now. It seems that the behavior I reported about jumping back one position no longer happens but now the Shield has the same, what I believe is wrong, behavior of the Fire as in it jumps all the way back to the beginning.

 

To add one more point about why that is wrong behavior consider that if there is a show at position six and the user wants to play four episodes in a row either in rotation of four different shows like I usually do or four episodes of the same show like this is designed to allow:

In the case of four episodes of the same show if the position in the next up is maintained you must:

Scroll right six places and press play

then, after the episode finishes, you must scroll left six places and press play

then, after the episode finishes, you simply press play

then, after the episode finishes, you simply press play again

That completes playing the four desired episodes and you have pressed an arrow key twelve times.

 

In the case of four episodes of different shows if the behavior is jump to the first episode after completion:

Scroll right six places and press play

Scroll right six places and press play

Scroll right six places and press play

Scroll right six places and press play

That completes playing the four desired episodes and you have pressed arrow keys twenty four times or twice the presses.

 

From the above it is pretty clear that the least intrusive way to handle the jump after completion is not to jump at all. That is it requires the lowest average number of keystrokes if you remain where you start in the next up list.

 

There is another way to handle both situations:

After playing an episode of a show you present a screen, like the preplay screen, with the next episode of the show just played ready to start playing and if you press back from that screen you are returned to the next up screen at the location you were when you started playing. That is a compromise behavior that I could live with and allows for easy binge watching.

 

BTW: Just because Plex uses that method does NOT make it bad. In fact the way Plex handles their On Deck and pre/post play is one of the things they have gotten right.

[maegibbons 1267]

The "right" answer is to work out how to stay in the last position rather than jumping to position 1, then make it an option for the user to decide how to use it.

 

This has been brought multiple times and still no movement in the "right" direction.

Absolutely. The ATV app is currently too jumpy. Lots of times when scrolling right it resets to the 1st position for no reason.

 

You need to look at these issues that we bring up and start fixing them.

 

Do feel we are being ignored at the moment and feel a slight position of "we know best" is creeping in to your mindset. You don't. Plex made that mistake.

 

Krs

 

Mark

[ebr 14937]

I spent some time on this today and I think you guys will like the result.

 

However, it won't go out for a day or two because I want to get a bug fix release out and there are too many fundamental changes in this change to risk pushing out at the last minute.

 

Thanks.

[CBers 6771]

Thanks Eric, looking forward to it.

[Gilgamesh_48 944]

I spent some time on this today and I think you guys will like the result.

 

However, it won't go out for a day or two because I want to get a bug fix release out and there are too many fundamental changes in this change to risk pushing out at the last minute.

 

Thanks.

 

Thanks. But I hate and detest waiting when I know something good is coming.

 

Yes, I know that statement has a redundancy in it but I also think we should stamp out and abolish  redundancy.

 

I will wait, mostly, with patience for the release of the new client. Waiting ... waiting ... waiting ...

[Gilgamesh_48 944]

@@ebr One more thing that I think is related to this.

 

I was browsing my Next play list and I was on about the 5th or 6th position. I accidentally touched "play" and the show tried to start to play. Before it could actually start, because I did not want to play that show at that time, I pressed "back" and the playback aborted.

 

The above action resulted in the falsely started episode moving to position #1 in Next up.

 

I believe that before an episode moves to the first position in next up the "Min resume percentage" should be exceeded. Moving just because an episode gets touched just seems wrong.

[ebr 14937]

I believe that before an episode moves to the first position in next up the "Min resume percentage" should be exceeded. Moving just because an episode gets touched just seems wrong.

 

This logic is currently managed by the server.  Once you start to play something, its last played date is updated.

[maegibbons 1267]

I spent some time on this today and I think you guys will like the result.

 

However, it won't go out for a day or two because I want to get a bug fix release out and there are too many fundamental changes in this change to risk pushing out at the last minute.

 

Thanks.

 

Yes... Thanks for looking at this.  Looking forwrd to seeing what you have done.

 

But we can be patient.

 

Krs

 

Mark

[ebr 14937]

Yes... Thanks for looking at this.  Looking forwrd to seeing what you have done.

 

But we can be patient.

 

Krs

 

Mark

 

The beta with the new behavior just went up.

[Gilgamesh_48 944]

The beta with the new behavior just went up.

 

Thanks!

 

I have just tested on my Shield (my Fire TV is waiting for the beta to actually update) and the behavior is now what I believe is correct.

 

In looking around I do not see a setting for this. Does that mean that everyone will be using the behavior we now see? I did not really want to force my desires on others, I just wanted choice.

 

I am unused to winning an interface debate or even getting a draw. In Plex I never convinced anybody in development about anything and it is REALLY refreshing to know you really listen.

 

Now to get everything else just like I want it all we need do is...

[ebr 14937]

The way it behaves now should be intuitive for all hopefully.  If the item you left from still exists in the refreshed list, you should stay on that item (where ever it is in the list).  Even if it is at the front now, you should see it animate with you to the front.  You can test this by playing something several spaces down your Continue Watching list and then stopping it while it still is within resume range.

 

If the item you left from is not in the new list, then you should see it just disappear and you stay on its adjacent item.

 

This is all achieved by not simply re-loading the list but, rather, re-retrieving the data for the new list and comparing it to the old list and then adding things that need to be added, removing things that need to be removed and updating things that need to be updated.  This allows us to keep the positional context and even do some cool animations for move, add and remove.

 

This also minimizes the visual disruption in that, if nothing within view changes, then you can't even tell the list has refreshed.

[CBers 6771]

Nice work Eric, thanks.

 

Been requesting this for ages

[maegibbons 1267]

Yes. Great work.

 

Thanks for listening.

 

Krs

 

Mark