Jump to content

Could not resume in-progress recordings


cncb
 Share

Recommended Posts

Watching recordings in progress yesterday (NFL games) was a total mess on my new Fire Cube.  I could not resume watching the recordings after stopping over an hour in.  I think this is due to the current transcoding necessary when watching in-progress recordings in Android.  Will TVNext improve this and if so, let's have it please?

Link to comment
Share on other sites

5 minutes ago, cncb said:

Watching recordings in progress yesterday (NFL games) was a total mess on my new Fire Cube.  I could not resume watching the recordings after stopping over an hour in.  I think this is due to the current transcoding necessary when watching in-progress recordings in Android.  Will TVNext improve this and if so, let's have it please?

Hi, that's not related to this. Please open a new topic and we'll be happy to help. Thanks.

Link to comment
Share on other sites

Trying to watch the in -progress NFL recordings yesterday on my new Fire Cube, I stopped over an hour in and then could not resume watching.  After about 5 minutes, the static image would update to the correct resume position, but it would never resume playing.  I waited for an additional 15 minutes and then just had to wait for the recording to finish before I could watch again.  Not a great experience.

embyserver-63810028800.zip

Link to comment
Share on other sites

47 minutes ago, Luke said:

Hi, that's not related to this. Please open a new topic and we'll be happy to help. Thanks.

I think some elaboration is needed to this.

His concern is certainly by current design of in-progress recordings and a resume point being anything greater than a couple of minutes. I witness this as well, and it is certainly as specified and accepted (albeit infuriating to wait). @softworkz knowing that the signal path and processing of the inputs within TvNext are different/more efficient, etc. would it have an impact on this use case? I personally hope so as well, but understand this is much larger than this one condition.

Link to comment
Share on other sites

15 minutes ago, bungee91 said:

I think some elaboration is needed to this.

His concern is certainly by current design of in-progress recordings and a resume point being anything greater than a couple of minutes. I witness this as well, and it is certainly as specified and accepted (albeit infuriating to wait). @softworkz knowing that the signal path and processing of the inputs within TvNext are different/more efficient, etc. would it have an impact on this use case? I personally hope so as well, but understand this is much larger than this one condition.

It's something that can be addressed in the current playback. Thanks.

Link to comment
Share on other sites

5 minutes ago, softworkz said:

I can't say for sure what really happened in your case, but my latest state of knowledge was that paused transcodings are terminated after like an hour or so of inactivity. This would match your case and probably (I might be wrong) - that's what Luke meant by "it can be addressed". Now, the timeout could be simply increased - but that might affect other use cases. Or the timeout can be increased only for Live TV - maybe. Typically something like that will be done to "address" this.

 

That's a very detailed reply (and the easiest solution is to just have more tuners; kidding) however the quoted part above in particular doesn't seem to align with expectations out of the box.

Example:

  • A 3-hr recording is occurring, now 2.5 hrs in.
  • I am watching and at 1.5hrs into the recording in the living room.
  • I stop watching, and a resume point for 1.5hrs is set.
  • I go to the bedroom to resume, literally 5-minutes after closing it in the living room.
  • It takes ~10 minutes to start playback.
    • Both ATV clients, both Shield TV's.

You're telling me this can be resolved in the current playback with some workaround or edits? I SO want to believe you, however I know in my previous research of this issue this was not the case at that time. Also by no means is my hardware not capable for reasonable expectation/performance. I will certainly start a new thread (or of course the requestor if @cncb does) to discuss this in further detail.

Link to comment
Share on other sites

2 minutes ago, bungee91 said:

You're telling me this can be resolved in the current playback with some workaround or edits?

No I'm not telling that. You're picturing a totally different situation. 

All I meant is that when you've experienced that you could not continue after pausing for 60min, then it would surely be possible to make it happen only after like 90min instead.

Link to comment
Share on other sites

3 minutes ago, softworkz said:

then it would surely be possible to make it happen only after like 90min instead.

But this cannot be open ended, as I said - no matter which value, it will always be wrong for somebody. Also, as paused live tv playback will usually be among the first session to be dropped when a tuner is needed for a certain action.

But with TVnext, you will be able to do the following: When you're watching and you know that you might want to take a longer break or you want to be sure that the session isn't dropped for some reason, you can simply hit record to record the current program. Unlike WMC, this will not drop your time-shift buffer and forward you to the "live time", from where recording starts - the opposite will happen: it will take everything (of the program to record) that's already in the time-shift buffer as the recording and will continue recording at the live edge. 

At any time, there's only a single time-shift buffer for a certain channel. The time-shift buffer data is the un-transcoded original stream and it is shared by multiple users watching a channel and by recordings running for the channel. That means - as long as the recording is running, the time-shift buffer will stay alive and you'll be in fact able to stop watching on one client and resume watching on another client later.

Link to comment
Share on other sites

26 minutes ago, softworkz said:

No I'm not telling that. You're picturing a totally different situation. 

All I meant is that when you've experienced that you could not continue after pausing for 60min, then it would surely be possible to make it happen only after like 90min instead.

Yes, very different situations. Again, this is all great detail and HUGE improvements to what is currently offered.

He was asking about resuming an in-progress recording and the delay. I asked the same with additional detail, and @Luke said it can be addressed in the current playback. I agree it is off topic here, however don't know if posting outside of here will gain any traction if there is no specific way to resolve this at this time and we just deal with it. I'll tell you WMC certainly didn't have that specific issue 🤭 (yes, I am mostly messing with you).

Link to comment
Share on other sites

10 minutes ago, bungee91 said:

don't know if posting outside of here will gain any traction if there is no specific way to resolve this

All support requests are taken seriously when all requested information is provided.

11 minutes ago, bungee91 said:

yes, I am mostly messing with you

I know you think you would. But you aren't. And I'm not going to tell you why.

Link to comment
Share on other sites

emveepee
9 hours ago, softworkz said:

No I'm not telling that. You're picturing a totally different situation. 

All I meant is that when you've experienced that you could not continue after pausing for 60min, then it would surely be possible to make it happen only after like 90min instead.

I thought both scenario's indicate that stop/resume where not working and don't appear to be related to the timeshift buffer, which can be addressed.   @cncb's other comment is puzzling too since there should be no technical need to transcode in-progress recordings to Android devices that can direct play, assuming you don't use ExoPlayer defaults.

Martin

Link to comment
Share on other sites

4 hours ago, emveepee said:

I thought both scenario's indicate that stop/resume where not working and don't appear to be related to the timeshift buffer, which can be addressed.   @cncb's other comment is puzzling too since there should be no technical need to transcode in-progress recordings to Android devices that can direct play, assuming you don't use ExoPlayer defaults.

Yes, I am talking about in-progress recordings as @bungee91 noted so I don't think it should have anything to do with the timeshift buffer.  Sorry, I meant remuxing for in-progress recordings which I was told a while ago was necessary for some reason.

Link to comment
Share on other sites

5 minutes ago, cncb said:

Yes, I am talking about in-progress recordings as @bungee91 noted so I don't think it should have anything to do with the timeshift buffer

Strictly speaking, current Emby doesn't really have a timeshift buffer. It writes a file from the incoming stream to disk (=>recording) and for playback it simultaneously lets ffmpeg read that stream for transcoding.

Besides that, I have understood the following:

  • You were making a TV recording with Emby
  • At the same time you watched the same program as Live TV with an Emby App
  • You watched for a while, then  paused the playback
  • After > 60min, you wanted to unpause and continue watching - which failed

Correct?

Link to comment
Share on other sites

47 minutes ago, softworkz said:

Besides that, I have understood the following:

  • You were making a TV recording with Emby
  • At the same time you watched the same program as Live TV with an Emby App
  • You watched for a while, then  paused the playback
  • After > 60min, you wanted to unpause and continue watching - which failed

Correct?

I was actually watching the recording from the Fire TV (Android) app.  I don't know if Emby treats this the same as watching Live TV.  I had watched > 60 minutes of the recording and then stopped it.  When I went to resume watching it from when I stopped point, it failed.  I started a thread for this as Luke requested: 

 

Link to comment
Share on other sites

5 minutes ago, cncb said:

Probably 30 minutes or so.

Okay, then I don't know what it is. I understood it as you would have waited 1h between stopping and resuming and this would have very likely been due to a timeout.

PS: I have moved all messages to your new topic. Thanks for creating!

Link to comment
Share on other sites

(That was confusing, however this being in a separate thread is fantastic to start talking about this area for improvement!)

The less technical explanation here: We know that Emby has to do something with the file in order to allow us to seek the in-progress recording (direct stream).

If at anytime you stop playback completely and get a resume point, and attempt to resume it (still an in-progress recording) it will take a LONG time to continue. In my use case this is with an ATV app, similar to his (Shield vs Fire). It normally will actually resume at some point, but it can literally take 30 minutes or so to do it.

My assumption is that for some reason the entire file has to be seeked through (processed, etc.) to get to this resume point in the file.

I'd love to understand this better, just always thought based on review of others experience/forum posts, this is known and by design as a limitation. I'd be really interested to know more, or even what client(s) or hardware wouldn't have this issue. 

  • Agree 1
Link to comment
Share on other sites

emveepee

Technically direct play will work ok on Android even with a ts stream if the client server agree on a protocol, but if TVnext does hls that will be more accurate.  It boils down to how long the segmenting takes to get going since recordings start so fast and any implications with comskip.

Martin

Link to comment
Share on other sites

12 minutes ago, softworkz said:

TVnext doesn't have such problems. Because it doesn't do DirectPlay 🙂 

Do you recommend Emby forcing transcoding for in progress recordings to allow it to resume and skip during a recording?

Link to comment
Share on other sites

29 minutes ago, bungee91 said:

at anytime you stop playback completely and get a resume point, and attempt to resume it (still an in-progress recording) it will take a LONG time to continue. In my use case this is with an ATV app, similar to his (Shield vs Fire). It normally will actually resume at some point, but it can literally take 30 minutes or so to do it.

The issue here, I believe, lies in the fact that the item is still recording (i.e. the file is constantly changing) and our resume mechanism is just not able to deal with that. 

Resume after the recording finishes works, correct? 

Link to comment
Share on other sites

Just now, ebr said:

Resume after the recording finishes works, correct? 

That is correct, works perfectly in that use case (sometimes the resume point can get lost with that change of condition, but can't recall the history there.  I believe ATV app deals with that now after you had made change but wasn't able to keep it prior to).

Link to comment
Share on other sites

27 minutes ago, ebr said:

The issue here, I believe, lies in the fact that the item is still recording (i.e. the file is constantly changing) and our resume mechanism is just not able to deal with that.  

Yes, agreed. I am able to skip all the way back to the resume point though. In less time than it takes letting resume get back to the resume point. So, if I can get back to the resume point with skipping, it seems the resume mechanism could be adjusted to get back quicker for in progress recordings. The issue that I see with skipping is that it goes all the way back to the beginning, and then I have to hold down the skip button to get back to the resume point. If I let go of the skip button at any point, it jumps all the way back to the beginning. I believe when i used this method I also had to change the quality of the video I was watching to 720p. It didn't change the quality of the recording, it seems to just forced transcoding for what I was watching. 

It's a lot of steps to go through manually to get it to kind of resume. Ideally something more elegant could be done behind the scenes.

Link to comment
Share on other sites

34 minutes ago, MBSki said:
47 minutes ago, softworkz said:

TVnext doesn't have such problems. Because it doesn't do DirectPlay 🙂 

Do you recommend Emby forcing transcoding for in progress recordings to allow it to resume and skip during a recording?

Oh - no, not at all. Transcoding should only be done when absolutely necessary.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...