ISSUE: After Upgrading to 3.2.9 Live TV Breaks

[theniteow1 25]

Hello Emby team!

 

I recently just upgraded to 3.2.9 and it breaks live TV significantly for me.  Just odd behavior, for one multiple channels can't be viewed at once.  If I am watching a Live TV channel and if someone else tunes into another channel on another TV, it will kick me out, and allow them to watch it on theirs.  However, if I then go back to watch what I want, it will kick them out.    Another thing, is if I tune to channel, and then switch to another channel.  It will keep showing the same channel, even though I selected another one.  It seems eventually it will switch, but it takes many times for it to do this.  I had to roll back to 3.2.7 for it to work properly.    I also tried 3.2.9.3 beta to see if that would resolve the issue, and same behavior.  I am using HDHOMERUN tuners and using the native Live TV interface, no add-ons. I've attached the logs from this morning before I rolled backed to 3.2.7 and from last night.  Thanks!

server-63626419447.txt

server-63626428800.txt

[Luke 37003]

Thanks for the report. We are looking into it.

[Luke 37003]

For those of you running the beta server, try 3.2.10.1 which just went up. Thanks.

[blade005 172]

For those of you running the beta server, try 3.2.10.1 which just went up. Thanks.

@@Luke,

 

Just tested 3.2.10.1 and it looks good.

 

• I just got six (6) Live TV streams up and running simultaneously on two (2) WebUI Clients, two (2) Android App clients and two (2) Emby Theater Desktop clients. Two (2) DLNA HDHomeRun tuners and one (1) older Non-DLNA HDHomeRun tuner.

 

• I also fired up four (4) simultaneous recordings and they all grabbed a separate tuner and recorded the correct channel.

 

I have a recording lineup tonight that will tax this crossover of pre and post padding of various channels and will report back on results.

 

Many thanks for such a quick response and fix. 

[Luke 37003]

Thanks for confirming.

[blade005 172]

@@Luke,

 

Just tested 3.2.10.1 and it looks good.

 

• I just got six (6) Live TV streams up and running simultaneously on two (2) WebUI Clients, two (2) Android App clients and two (2) Emby Theater Desktop clients. Two (2) DLNA HDHomeRun tuners and one (1) older Non-DLNA HDHomeRun tuner.

 

• I also fired up four (4) simultaneous recordings and they all grabbed a separate tuner and recorded the correct channel.

 

I have a recording lineup tonight that will tax this crossover of pre and post padding of various channels and will report back on results.

 

Many thanks for such a quick response and fix. 

@@Luke

 

UPDATE:

1. Simultaneous recordings across multiple channels working as expected. Each scheduled recording grabbed their own tuner.
2. Back-to-back recordings of the same channel are still an issue. The first recording grabs a tuner and begins recording. The second recording on the same channel begins a pre-padded recording using the same tuner with no issue. Once the first recording ends its post-padding recording, the second recording is also stopped and creates a 5 minute file (2 minutes pre-padding for second recording and 3 minutes post-padding from first recording). A second file is then kicked off for the remainder of the second recording on the same tuner. Result for the second recording on the same channel is a 5 minute file and a 30 minute file appended with a -1.

FYI. On HDHomeRun firmware Version 20161117. Pre and Post padding on the same channel using only one tuner has been working properly until recently.

Edited March 31, 2017 by blade005

[blade005 172]

@@Luke

 

HDHomerun stream sharing is still not functioning properly in 3.2.10.2beta.

 

When the first recording of a channel ends, it also stops the recording session of the next recording that has begun on the same channel, resulting in a truncated 5 minute file. It will then start up an appended file for the remainder of the recording time. If you then have a third recording scheduled on the same channel it will also get truncated into two (2) files as the second recording ends.

 

Here is what I am experiencing if I schedule three (3) recordings on the same channel that overlap with pre and post padding.

• 7pm recording on CBS begins at 6:58pm and runs until 8:03pm. One (1) 65 minute file is created.
• 8pm recording on CBS begins at 7:58 pm and is stopped at 8:03pm when 7pm recording ends. A second recording session is then immediately started up on the same tuner and runs until 9:03pm. Result is one (1) 5 minute file and one (1) 60 minute file appended with a -1.
• 9pm recording on CBS begins at 8:58pm and runs until 9:03pm when 8pm recording ends. A second recording session is then immediately started up on the same tuner and runs until 10:03pm. Result is one (1) 5 minute file and one (1) 60 minute file appended with a -1.

Stream sharing is nice if it is working, but this is creating a bit of a messy file organization issue.

 

I have additional tuners available in my setup while these back-to-back sessions on the same channel seem to step on each other trying to share one stream with pre and post pad overlap. It would be nice if there was an option to have these second and third scheduled recordings grab another tuner to begin their session, if available.

[Luke 37003]

Make sure to accompany this with how to report a problem. thanks.

[blade005 172]

Make sure to accompany this with how to report a problem. thanks.

@@Luke,

 

Did my best here to re-create what is happening when shared stream overlaps and first recording finalizing causes the second recording to be stopped. Let me know if there is anything else you may need. Thanks.

 

Emby Server: 3.2.10.2beta

HDHomeRun Connect Firmware Version: 20161117

 

SCENARIO:

• Two (2) shows on PBS (Channel 13.1) scheduled to record that are back-to-back.
• Recording 1: ASK THIS OLD HOUSE -- Recording 2: A CRAFTMAN'S LEGACY
• Pre-Padding of 2 minutes. Post-Padding of 3 minutes. Creates a 5 minute overlap where both shows are sharing the tuner stream.

I manually started Recording 1 as it was already in progress. It grabs a tuner and begins recording. Recording 2 begins, using the same tuner stream. When Recording 1 ends after the 3 minute post-padding and finalizes, Recording 2 is also stopped and writes a 5 minute in length file. Another process then starts up, grabs the tuner back and begins a session that records the remainder of scheduled Recording 2, resulting in a 30 minute in length file.

 

Attached are the Emby server logs and a snapshot of the files created for Recording 2.

 

Emby Server Log: http://paste2.org/J6gUhvnh

 

Recording 2 (A CRAFTMAN'S LEGACY) created files.

 

UPDATE: Saw Emby Server 3.10.2.3beta after I posted. Installed, restarted and tried the same scenario with the same split file result on second recording.

 

@ posted in another thread a similar scenario. If a channel is being recorded and you open the same channel in an app and watch it LIVE, when you stop watching the LIVE stream you will also stop the recording session for that channel.  https://emby.media/community/index.php?/topic/46301-recording-started-and-stopped/

Edited April 1, 2017 by blade005

[puithove 208]

Ran into this on 3.2.10.1 - back to back recordings on same channel ended up with the second recording being a 2-minute file (I have 1-minute pre & post padding).

[blade005 172]

Ran into this on 3.2.10.1 - back to back recordings on same channel ended up with the second recording being a 2-minute file (I have 1-minute pre & post padding).

@@puithove,

 

Thanks for confirming. At least I am not alone!

 

I have 2 pre and 3 post padding minutes, so I end up with a 5-minute file. But, Emby does start up a second recording session for the second show. I am just not sure how much of the show is missed in between. I guess while the Devs investigate, we could try removing the pre and post padding and see if we get single file recordings, since stream sharing isn't being nice with back-to-back recordings on the same channel.

[maegibbons 1267]

Yes - I am also seeing this.  I have 2 and 2 set so I am getting a 4 minute 1st file.

 

Krs

 

Mark

[blade005 172]

@@Luke,

 

Did my best here to re-create what is happening when shared stream overlaps and first recording finalizing causes the second recording to be stopped. Let me know if there is anything else you may need. Thanks.

 

Emby Server: 3.2.10.2beta

HDHomeRun Connect Firmware Version: 20161117

 

SCENARIO:

• Two (2) shows on PBS (Channel 13.1) scheduled to record that are back-to-back.
• Recording 1: ASK THIS OLD HOUSE -- Recording 2: A CRAFTMAN'S LEGACY
• Pre-Padding of 2 minutes. Post-Padding of 3 minutes. Creates a 5 minute overlap where both shows are sharing the tuner stream.

I manually started Recording 1 as it was already in progress. It grabs a tuner and begins recording. Recording 2 begins, using the same tuner stream. When Recording 1 ends after the 3 minute post-padding and finalizes, Recording 2 is also stopped and writes a 5 minute in length file. Another process then starts up, grabs the tuner back and begins a session that records the remainder of scheduled Recording 2, resulting in a 30 minute in length file.

 

Attached are the Emby server logs and a snapshot of the files created for Recording 2.

 

Emby Server Log: http://paste2.org/J6gUhvnh

 

Recording 2 (A CRAFTMAN'S LEGACY) created files.

 

UPDATE: Saw Emby Server 3.10.2.3beta after I posted. Installed, restarted and tried the same scenario with the same split file result on second recording.

 

@ posted in another thread a similar scenario. If a channel is being recorded and you open the same channel in an app and watch it LIVE, when you stop watching the LIVE stream you will also stop the recording session for that channel.  https://emby.media/community/index.php?/topic/46301-recording-started-and-stopped/

@@Luke

 

A number of users are experiencing this issue with back-to-back recordings on same channel and stream sharing not allowing the second recording to continue as the first recording ends. Any chance you can take a look at the information provided in Post #9 and let me know if you need anything else.

 

Many thanks.

[maegibbons 1267]

Cannot understand why this issue is not getting any traction in terms of investigation and resolution!! 

 

Its quite a big problem.

 

@@Luke is it that you cannot recreate the problem?  Do you need more detail?

 

Krs

 

Mark

[Luke 37003]

Thank you for your patience.

[maegibbons 1267]

Patience is not a problem when we know its being looked at.

 

Many thanks, once again, for all your hard work.

 

It is appreciated.

 

Krs

 

Mark

[blade005 172]

Thank you for your patience.

@@Luke

 

Tested Emby Server 3.2.10.5-beta and stream sharing of the same channel in back-to-back recordings is working as expected again. The stopping of the first recording is not impacting the second recording and splitting the file.

 

Many thanks.

 

@@maegibbons, @@puithove, @

 

Give 3.2.10.5-beta a try. Fixed the issue of back-to-back recordings for me and it will probably resolve the issue of watching a channel Live that is also being recording and not being affected by you stopping the Live TV stream.

[Guest asrequested]

I'll test it tonight

[Luke 37003]

Thanks for the feedback.

[lifespeed 42]

I'm glad to have read this thread.  I noticed the problem also, but was uncertain how to characterize it.  Thanks to @@blade005 for the careful description and Luke for fixing it.  I guess I'll look for the released server version before updating.

[maegibbons 1267]

Hi

 

3.2.10.5 has NOT fixed this for me.

 

Please look at the attached log.

 

At 20.58 "Pawn Stars/Season 10/Pawn Stars S10E16 Pinball Punch.ts" STARTS recording

 

At 21.28 "Pawn Stars/Season 10/Pawn Stars S10E02 Fireworks and Freedom.ts"  STARTS recording

 

At 21.32 "Pawn Stars/Season 10/Pawn Stars S10E16 Pinball Punch.ts" STOPS recording

 

The problems is so does "Pawn Stars/Season 10/Pawn Stars S10E02 Fireworks and Freedom.ts" due to errors

 

Krs

 

Mark

 

server-hdhroverlap.txt

[Spaceboy 2493]

Also just to join this thread, we see the same with recordings from an m3u source. Exactly the same.

[blade005 172]

Hi

 

3.2.10.5 has NOT fixed this for me.

 

Please look at the attached log.

 

At 20.58 "Pawn Stars/Season 10/Pawn Stars S10E16 Pinball Punch.ts" STARTS recording

 

At 21.28 "Pawn Stars/Season 10/Pawn Stars S10E02 Fireworks and Freedom.ts"  STARTS recording

 

At 21.32 "Pawn Stars/Season 10/Pawn Stars S10E16 Pinball Punch.ts" STOPS recording

 

The problems is so does "Pawn Stars/Season 10/Pawn Stars S10E02 Fireworks and Freedom.ts" due to errors

 

Krs

 

Mark

I reported that it was fixed in the initial test I performed, but perhaps further testing is needed.

 

I did have one back-to-back recording fail later that evening, but I can't be sure that it wasn't a reception issue as it spawned a bunch of small files. However, I did have a back-to-back recording one hour later that worked as expected. What I am not sure of is if they shared the same channel stream and transitioned as we would expect, or if the second recording actually grabbed another tuner.

 

@@Luke,

Should we be seeing back-to-back recordings sharing the same tuner and transitioning from the first recording ending to the second recording continuing gracefully, or did you implement a solution where back-to-back recordings on the same channel has the second recording grab another tuner?

[theniteow1 25]

I can confirm I'm also seeing the same issue.  Different channels can be viewed on multiple devices, but if the SAME channel is viewed on multiple devices, it will kick out whoever is already tuned in to accommodate the new device.  I can only assume this is the same behavior with recordings.

[blade005 172]

I can confirm I'm also seeing the same issue.  Different channels can be viewed on multiple devices, but if the SAME channel is viewed on multiple devices, it will kick out whoever is already tuned in to accommodate the new device.  I can only assume this is the same behavior with recordings.

Correct. Second, or on-going recording on stream is stopped when first recording ends.

 

@@Luke

I may have spoken too soon on successful stream sharing test. Perhaps the successful test meant the second recording grabbed another tuner and wasn't affected by first recording ending. Is that possible?