Recording Stopped Due to Shared Stream/In-Progress Watching =(

[bungee91 108]

I thought you guys fixed this one a long while ago, but has bit me twice lately. You're likely keeping me from watching bad football (the Chicago Bears lately!), however still a serious issue for me.

Issue: An in-progress recording is stopping prematurely due to the stream being watched (and likely exited) by another user at the same time.

Recording in question: NFL Football 2024_11_10_12_00_00 - New England Patriots at Chicago Bears

2024-11-10 14:03:44.445 Info SharedHttpPipelineSource: SharedHttpPipelineSource is done streaming.
2024-11-10 14:03:44.445 Info Server: http/1.1 Response 200 to 127.0.0.1. Time: 7873278ms. GET http://127.0.0.1:8096/LiveTv/LiveStreamFiles/1b97d0b293e344e7b1591c628b912680/stream.ts
2024-11-10 14:03:44.445 Info Server: http/1.1 Response 200 to 127.0.0.1. Time: 6905377ms. GET http://127.0.0.1:8096/LiveTv/LiveStreamFiles/1b97d0b293e344e7b1591c628b912680/stream.ts
2024-11-10 14:03:44.447 Info LiveTV: Recording stopped: /mnt/user/Recorded_TV/NFL Football (2023)/NFL Football 2024_11_10_12_00_00 - New England Patriots at Chicago Bears.ts
2024-11-10 14:03:44.448 Info App: AppendExtraLogData - Read graph file: /config/logs/ffmpeg-directstream-ff6da435-e788-4a90-9e6b-015c1168fe62_1graph.txt
2024-11-10 14:03:44.448 Info App: AppendExtraLogData - Deserialized GraphData fileStream: 27.000 bytes Graph Count: 0
2024-11-10 14:03:44.448 Info App: AppendExtraLogData - File Deleted
2024-11-10 14:03:44.448 Info App: ProcessRun 'StreamTranscode ff6da4' Process exited with code 0 - Succeeded

Full log attached. Please review/fix this ASAP.  I have 8 tuners, and the user did not tell it to stop recording.

I can tell in the activity that the time aligns with the user exiting the stream. I don't think they did so intentionally either, just bad connection or whatever is likely the reason for them stopping.

 

Full log attached. Happened two weeks ago as well, but believe that log has been deleted by now (if not I can retrieve it). Thank you!

embyserver-63866876399.txt

[bungee91 108]

In the words of DJ Khalid, anotha one. 

See log. Confirm you see the issue. Please fix it. 

This example is "Green Bay Packers at Chicago Bears.ts". The Lions game recorded at the same time for +1 hour from the guide (same) is the expected 4+ hour recording. This one was just over 3hr, and not as intended. I've since updated to x.31, but I don't see anything from the release notes that would help with this.

embyserver-63867481199.txt

[Carlo 4486]

Hi,

I didn't see anything wrong with this recording. No errors, no one logging off no one stopping playback.

Carlo

[bungee91 108]

2 hours ago, Carlo said:

Hi,

I didn't see anything wrong with this recording. No errors, no one logging off no one stopping playback.

Carlo

Hi @Carloappreciate you looking into this.

The most recent one, or the first one?

The first example I'm fairly certain that is what is shown, and the recording stopped well before it was intended to be completed (unless football is only 2 1/4 quarters?...LOL).

The most recent one I can't say that I looked in the log enough to say one way or another. I can say however that the same Keyword recording for NFL Football is set with a +1 hour padding, so =~4hr. The recording length is 3hr and 9min, which is not by design or as requested. Something stopped it, and it wasn't me (and I see no reason a user ever would). There are 8 tuners, and space is not of concern. 

[Carlo 4486]

I didn't see anyone playing this stream until after it was done recording.  No errors related to this stream.

I did notice it being requested to transcode as it exceeded the bitrate set at 1.5Mb/sec
Any reason you have this set so low?

[bungee91 108]

4 hours ago, Carlo said:

I didn't see anyone playing this stream until after it was done recording.  No errors related to this stream.

I did notice it being requested to transcode as it exceeded the bitrate set at 1.5Mb/sec
Any reason you have this set so low?

For the first one it ended way early, and I could (admittedly quickly) tie it's stop to when they ended.

I don't know specifically about "errors", I just know both stopped prior to their scheduled recording times. The first example much sooner than the 2nd.

For the transcode question, based on my hardware it isn't an issue. However the user (likely/assuming) did so to conserve data if only listening to the audio while being distracted on other items.

[bungee91 108]

[HappyZombiSlayr 7]

I’d also like to add that I’ve noticed the same problem of LiveTV recordings being prematurely halted when the same stream is watched (and then exited) by a user.

 

I am currently at college, and have witnessed this the entire semester so far. Originally, I thought it could be a problem in directly using HD HomeRun on Emby.

A few weeks back, I switched to NextPVR to see if that would make any difference.

Still, when watching a stream while recording — Saturday Night Live, for instance — the recorded portion never exceeds the total time I’m watching the stream added to the length it was recording before I started watching. This is no different than before switching to NextPVR.

[Carlo 4486]

Thanks,

We are looking into this.

Carlo

Edited November 30, 2024 by Carlo

[Luke 38874]

HI, are you still having an issue with this?

[bungee91 108]

I won't have the right test conditions lately to confirm this is still an issue, as my sports team (Chicago Bears) is fairly awful so none of my family members have regularly been watching the game during an in-progress recording.

I don't however see anything in the release notes that would be directed at this issue. Can you please let me know if something has changed recently to expect this being resolved?Appreciate it if so, but my assumption without seeing as much is that this remains an open issue.