Consequences of PR #3704

[opusforlife2]

PR #3704 rightly retains queue items in case the user still wants them. It just skips to the next stream in the queue. But now 2 new cases need to be handled:

1. What to do when the faulty stream is the only item in the queue? (start playing/enqueue in background/popup when queue is empty)

2. What to do when the faulty stream is the last item in the queue?

Currently, for case 1, Newpipe just continues showing the buffering indicator after the error toast is gone. We have to swipe away the stream or close the player ourselves.

Solution: Ideally, since the faulty stream was the only item in the queue, it should be booted off, and the background/popup player should close on its own.

For case 2, Newpipe does exactly the same. Keeps showing the buffering indicator. I guessed that if Repeat queue was toggled on, Newpipe would loop back to the first stream if the last one in the list gave an error, but that doesn't happen. Moreover, removing the faulty stream doesn't help. The other working streams don't play on their own.

Solution: loop back to the start of the queue.

Moreover, in case 1, the stream name and channel name aren't shown for the stream, even when they're known to Newpipe (I can see them in the list).

In case 2, it's much worse. Here, the stream and channel name shown are for the previous stream, so the user may incorrectly conclude that it is the second last stream which is faulty, not the last one. This is another problem.

Solution? : Newpipe can use the stream and channel name from the list. I can't think of a case where this wouldn't be true.

[Stypox]

Ideally, since the faulty stream was the only item in the queue, it should be booted off, and the background/popup player should close on its own.

This could be a good solution for case 1, but I am not completely sure whether deleting the queue is ok, maybe someone would like to retry playing the same stream.

loop back to the start of the queue.

I considered this option, but with recurring errors (e.g. no network connection) the queue would keep looping, trying to download video info pages, drawing battery, consuming data and eventually causing recaptchas to appear, so I don't think this is a good idea.

Here, the stream and channel name shown are for the previous stream, so the user may incorrectly conclude that it is the second last stream which is faulty, not the last one. This is another problem.

This is more of an issue with the player: when changing stream, the old title stays in place until it is loaded.

[opusforlife2]

Ah. Fair enough for the first two. I didn't realise that you could tap on the faulty stream to retry it. Now it makes sense.

when changing stream, the old title stays in place until it is loaded.

Yeah, this should definitely be modified so that the stream that's about to be loaded is the one whose info is shown.

[opusforlife2]

@Stypox Do you have time to look at this right now?

[whistlingwoods]

@opusforlife2 is this still a issue?
..then it needs a relook.

[opusforlife2]

Ah.

This has changed completely. Upon encountering a broken queue item, the app now generates an error notification and plays a blank 2 second audio, after which:

• playback stops if it's the last queue item
• the next queue item starts playing

So I would consider this issue "fixed" in the sense that it doesn't confuse or mislead the user, and allows easy removal of the broken queue item.

@Stypox Was this fix intentional? That 2 second blank audio seems like an artifact.

[Stypox]

I don't remember it being intentional, but yeah, this seems fixed. I don't know about the two seconds, probably it's just the time spent loading.