Jump to content

Live TV plays but fails


mhaider60

Recommended Posts

mhaider60

I just tried beta 174 on both my Premiere + and series 3, unfortunately the problem still exists, seems to fail sooner now too. Would log files help?

Link to comment
Share on other sites

I just tried beta 174 on both my Premiere + and series 3, unfortunately the problem still exists, seems to fail sooner now too. Would log files help?

 

Yes. Log files or ffmpeg or both of any failed sessions.

 

We found and fixed 3 issues directly related to LiveTV. One was when the stream url was invalid it would attempt to recover. Now it fails gracefully. The second was in regards to not recovering when the error was no playlist given or the stream contained any DRM. The third now is to fail also when the stream Times Out regardless if this is LiveTV or Video on Demand. Either way. Normal playback on a Roku it sees as Video-On-Demand.

 

Is this stuck on "Retrieving" or does it say "Loading" there is a difference. When you say "still exists the problem" you mean the Video Player hangs, correct? Making sure I am not crossing wires here. Trying to do many things at once. We may also ask for access to your server to experience the issue ourselves. Both me/Shawn (@speechles) and Eric (@ebr) would be quite interested to get an invite to your server. We would also need steps to reproduce your issue if this is fully reproduceable. We just need access to your server and the steps to replicate. Thanks.

Edited by speechles
Link to comment
Share on other sites

mhaider60

The problem is it gets stuck on "Retrieving" and the video player hangs. 

 

What username/email should I send a server invite to?

 

I attached 2 ffmpeg files, I tried 2 channels this morning, one OTA one cablecard, I'm guessing these 2 files were for those events.

 

Thanks!

Mark

embyserver.txt

ffmpeg-remux-ee48974e-3d5b-486b-9d70-a370e384efde_1.txt

ffmpeg-remux-4d36ff3d-4d8b-44a7-afb7-d5254d870a7b_1.txt

Edited by mhaider60
Link to comment
Share on other sites

  Stream #0:0 -> #0:0 (copy)

  Stream #0:1 -> #0:1 (ac3 (native) -> aac (native))

 

It has to be something in ffmpeg. It is not just copying both streams. If it were I would say it could be the application on roku. SInce audio is being converted it changes things. When the stream goes kaput(OTA drops out) and ffmpeg is encoding audio like this it should cleanly break. Something is keeping the Roku player waiting for data. Emby isn't aware. Ffmpeg has stopped sending back data to the Roku and it puts the player into a broken state. Once in the broken state and it attempts to recover you experience the hang. The only error we allow fallback through on liveTV is the -3 unknown. Since we don't know what caused that error we attempt to fully transcode to resolve it. Maybe with liveTV we should also bail on -3 as well. Might make that change.

 

Reference: Fix #501: [LiveTV] Bail on any error with LiveTV 

Edited by speechles
Link to comment
Share on other sites

  • 2 weeks later...

If you're willing to try the beta server, it's possible there will be a difference when using that.

Link to comment
Share on other sites

mhaider60

If you're willing to try the beta server, it's possible there will be a difference when using that.

 

I've been using the beta server for quite a few versions.

 

Thanks for the suggestion tho

Link to comment
Share on other sites

mhaider60

I was thinking maybe you slipped a fix for this into beta .179 when I got 30 minutes of live TV playback this morning, but then the "Retrieving" showed up.  :(

Link to comment
Share on other sites

I was thinking maybe you slipped a fix for this into beta .179 when I got 30 minutes of live TV playback this morning, but then the "Retrieving" showed up.  :(

 

Just to be clear, when this happens it is due to a disruption of the stream and we can't really "fix" that from the app.  The best we could do is just abort when it happens if we can detect it.  Our attempts to retry seem to be failing but we may also be able to perfect that (assuming it is a very temporary disruption).

Link to comment
Share on other sites

mhaider60

Just to be clear, when this happens it is due to a disruption of the stream and we can't really "fix" that from the app.  The best we could do is just abort when it happens if we can detect it.  Our attempts to retry seem to be failing but we may also be able to perfect that (assuming it is a very temporary disruption).

 

What happens if the stream gets disrupted when it's being recorded? The recording just doesn't quit. Couldn't live TV just play off a buffer? I'm not an expert at any of this so I'm not trying to tell you how to do it. My Nvidia Shield handles live TV just fine with the Emby app, but I'd prefer not to buy another one when I have a perfectly good Roku, and not to be a smart a$$, but live TV on the Roku is the only thing I continue to use Plex for.

Link to comment
Share on other sites

What happens if the stream gets disrupted when it's being recorded? The recording just doesn't quit. Couldn't live TV just play off a buffer? I'm not an expert at any of this so I'm not trying to tell you how to do it. My Nvidia Shield handles live TV just fine with the Emby app, but I'd prefer not to buy another one when I have a perfectly good Roku, and not to be a smart a$$, but live TV on the Roku is the only thing I continue to use Plex for.

 

The problem is the fragility of the player built into the Roku.  When it gets into this state, it is out of the app's control.  In order to retry in this situation, we'd have to discover the player went into this state and then set some sort of timer to see how long it stays there and, at some point, potentially stop and retry.  That is something we can look into but not something the app tries to do at this time.

 

The other platforms both have more robust players and more control available to the app within those players.

 

Thanks.

Link to comment
Share on other sites

mhaider60

The problem is the fragility of the player built into the Roku.  When it gets into this state, it is out of the app's control.  In order to retry in this situation, we'd have to discover the player went into this state and then set some sort of timer to see how long it stays there and, at some point, potentially stop and retry.  That is something we can look into but not something the app tries to do at this time.

 

The other platforms both have more robust players and more control available to the app within those players.

 

Thanks.

 

I appreciate your situation and for the reason I switched to Emby I can live with this for now, I'm much happier with Emby. I must be the only person that uses live TV on a Roku.

Link to comment
Share on other sites

. I must be the only person that uses live TV on a Roku.

 

I don't think so.  Rather, I think something about your streams are particularly challenging for the platform.

Link to comment
Share on other sites

mhaider60

I don't think so.  Rather, I think something about your streams are particularly challenging for the platform.

 

I have two HDHome runs, one is OTA the other is cablecard and it happens to both. I have a CAT5 wired network.

Link to comment
Share on other sites

I have two HDHome runs, one is OTA the other is cablecard and it happens to both. I have a CAT5 wired network.

 

I have issues with streams with where I live(Ukiah, California) and OTA broadcasts because I am on the fringe of the direction the signal is repeated. So during high photon activity aka a bright sunny day those extra electrons being pushed by those photons help carry the radio broadcast more my direction (magnetosphere radiation/atmospheric reflection). I can actually get KPIX channel 5(San Francisco) at 10AM PST which means yep. "Price is Right" time! But If I try again at 2pm nope. At 10AM I get a blended signal of the original San Francisco signal (via Skip) plus the repeated (local repeater on a mountain top aimed 120 degrees away from me) on top so the signal is strong enough. At 2PM I just get the fringe effect of the signal and not enough to sustain bitrate. It keeps drop to 0 and reset the tuner. It never "captures" the signal. I get refused on my Roku. I used to do Hobbyist amateur radio stuff and have a call sign. This broadcast TV is no different. The TV has a demodulator. If the signal it demodulates changes bitrate below the error correction rate you must reset the demodulation.

 

Not gonna even be possible because the curvature of the Earth changed the direction of photons striking Earth and their ability to penetrate and the "skip" I was getting is gone.

 

Radio waves have this phenomenon known as "Skip" that can adversely affect signal propagation. You might get a "good effect" like me and during high skip times the signal works better. Or you might get adverse affects from it.

 

Where is your OTA antenna located? How is line of sight to the transmitter/repeater? Is there any way to raise your antenna location with a mast or similar?

Edited by speechles
Link to comment
Share on other sites

mhaider60

 

I have issues with streams with where I live(Ukiah, California) and OTA broadcasts because I am on the fringe of the direction the signal is repeated. So during high photon activity aka a bright sunny day those extra electrons being pushed by those photons help carry the radio broadcast more my direction (magnetosphere radiation/atmospheric reflection). I can actually get KPIX channel 5(San Francisco) at 10AM PST which means yep. "Price is Right" time! But If I try again at 2pm nope. At 10AM I get a blended signal of the original San Francisco signal (via Skip) plus the repeated (local repeater on a mountain top aimed 120 degrees away from me) on top so the signal is strong enough. At 2PM I just get the fringe effect of the signal and not enough to sustain bitrate. It keeps drop to 0 and reset the tuner. It never "captures" the signal. I get refused on my Roku. I used to do Hobbyist amateur radio stuff and have a call sign. This broadcast TV is no different. The TV has a demodulator. If the signal it demodulates changes bitrate below the error correction rate you must reset the demodulation.

 

Not gonna even be possible because the curvature of the Earth changed the direction of photons striking Earth and their ability to penetrate and the "skip" I was getting is gone.

 

Radio waves have this phenomenon known as "Skip" that can adversely affect signal propagation. You might get a "good effect" like me and during high skip times the signal works better. Or you might get adverse affects from it.

 

Where is your OTA antenna located? How is line of sight to the transmitter/repeater? Is there any way to raise your antenna location with a mast or similar?

 

I could probably improve my OTA location/signal, but it hasn't been an issue until I started using Emby and the Roku app. I also have the HDHomerun Prime cablecard tuner, it does the same exact thing. This morning using the Emby Roku app I tuned to a channel on the CC tuner, it played for 17 minutes and "Retrieving" popped up. I switched to the Plex Roku app, tuned to my favorite OTA channel and it played non-stop for over an hour, turned it off when I left for work. While the OTA channel was playing on Plex, I fired up the Emby app on my Nvidia Shield, tuned to the same OTA channel and it too played non-stop until I left for work. 

 

I really like Emby and I'm so glad I gave it a try, it's my "go to" now over Plex. Emby has a DVR that is far better, that being said, the problem I'm having with live TV on the Roku is only disappointing, the DVR problem I have with Plex just plain makes me mad. For now I will continue to do what I have been doing, Emby for most stuff, Plex for live TV on the Roku. When I see a new version of the Emby Roku beta is available I will try live TV it to see if works for me, if not I switch over to Plex, it's not a hardship.

 

Just so you know, I really appreciate that you guys at Emby at least communicate with your customers, Plex lack of communication is another thing that frustrates me.

Link to comment
Share on other sites

@@mhaider60

 

The issue isn't going to be the Roku but how ffmpeg is dealing with these drop outs. Especially if hardware acceleration is involved. These are areas we need to do better.

 

With the Roku it is 100% dependent on ffmpeg to convert to HLS to allow the TS stream to seek. It is this which causes the problem. If we allowed direct play this would play quicker and remove that buffering but you would not be able to seek the stream. Just pause/play and rew/ff through the pause buffer. You would not be able to hold pause beyond 30 minutes without ffmpeg involved. The Roku player would actively unpause and begin playback once its progress buffer filled. 

Link to comment
Share on other sites

osealion

Seeing what I think is the same issue with a Linux Server 4.2.0.36.

 

LiveTV starts, then dies after a few minutes, restarting after that and it's usually OK.

[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8.tmp' for writing
SegmentComplete=video:0 Index=44 Start=132.015222 End=135.001544 Duration=2.986322 offset_pts=0 start_pts=132015222 Frames=179 filename=hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0044.ts
[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a0045.ts.tmp' for writing
elapsed=00:02:12.24 frame= 8146 fps= 62 q=-0.0 size=  134805kB time=00:02:15.83 bitrate=8129.8kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:12.74 frame= 8181 fps= 62 q=-0.0 size=  135353kB time=00:02:16.41 bitrate=8128.0kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:13.25 frame= 8211 fps= 62 q=-0.0 size=  135851kB time=00:02:16.92 bitrate=8128.0kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:13.75 frame= 8238 fps= 62 q=-0.0 size=  136286kB time=00:02:17.37 bitrate=8127.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:14.25 frame= 8265 fps= 62 q=-0.0 size=  136636kB time=00:02:17.82 bitrate=8121.5kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:14.75 frame= 8295 fps= 62 q=-0.0 size=  137263kB time=00:02:18.32 bitrate=8129.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8.tmp' for writing
SegmentComplete=video:0 Index=45 Start=135.001533 End=138.004544 Duration=3.003011 offset_pts=0 start_pts=135001533 Frames=180 filename=hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0045.ts
[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a0046.ts.tmp' for writing
elapsed=00:02:15.25 frame= 8322 fps= 62 q=-0.0 size=  137710kB time=00:02:18.77 bitrate=8129.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:15.85 frame= 8355 fps= 61 q=-0.0 size=  138198kB time=00:02:19.32 bitrate=8125.9kbits/s dup=86 drop=0 throttle=off speed=1.03x    

[q] command received. Exiting.

[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8.tmp' for writing
SegmentComplete=video:0 Index=46 Start=138.004533 End=139.756289 Duration=1.751756 offset_pts=0 start_pts=138004533 Frames=105 filename=hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0046.ts
elapsed=00:02:16.16 frame= 8377 fps= 62 q=-0.0 Lsize=  138534kB time=00:02:19.72 bitrate=8122.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
video:135256kB audio:3278kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
T=5.126s
Local Time: 22:47:48
[aac @ 0x16cc2c0] Qavg: 194.981

and

2019-07-29 22:47:45.464 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/videos/299232/live.m3u8?DeviceId=VHJpYW5nbGUgVFY1&MediaSourceId=native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&PlaySessionId=c39c048bf93e46ecaa64dc094848b35d&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&VideoCodec=h264&AudioCodec=aac,mp3&VideoBitrate=139616000&AudioBitrate=384000&MaxWidth=1920&AudioStreamIndex=-1&TranscodingMaxAudioChannels=6&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&h264-profile=high,main,baseline,constrainedbaseline&h264-level=42&aac-audiochannels=2&TranscodeReasons=ContainerNotSupported. Host=192.168.0.12:8096, Connection=keep-alive, Origin=https://mediabrowser.github.io, User-Agent=Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768, Accept=*/*, Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.9, CAST-DEVICE-CAPABILITIES={"bluetooth_supported":false,"display_supported":true,"hi_res_audio_supported":false,"remote_control_input_supported":false,"touch_input_supported":false}
2019-07-29 22:47:45.465 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 1ms. http://192.168.0.12:8096/emby/videos/299232/live.m3u8?DeviceId=VHJpYW5nbGUgVFY1&MediaSourceId=native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&PlaySessionId=c39c048bf93e46ecaa64dc094848b35d&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&VideoCodec=h264&AudioCodec=aac,mp3&VideoBitrate=139616000&AudioBitrate=384000&MaxWidth=1920&AudioStreamIndex=-1&TranscodingMaxAudioChannels=6&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&h264-profile=high,main,baseline,constrainedbaseline&h264-level=42&aac-audiochannels=2&TranscodeReasons=ContainerNotSupported
2019-07-29 22:47:45.743 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/videos/299232/hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0044.ts. Host=192.168.0.12:8096, Connection=keep-alive, Origin=https://mediabrowser.github.io, User-Agent=Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768, Accept=*/*, Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.9, CAST-DEVICE-CAPABILITIES={"bluetooth_supported":false,"display_supported":true,"hi_res_audio_supported":false,"remote_control_input_supported":false,"touch_input_supported":false}
2019-07-29 22:47:46.561 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 819ms. http://192.168.0.12:8096/emby/videos/299232/hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0044.ts
2019-07-29 22:47:48.342 Info HttpServer: HTTP OPTIONS http://192.168.0.12:8096/emby/Sessions/Playing/Stopped. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.343 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 0ms. http://192.168.0.12:8096/emby/Sessions/Playing/Stopped
2019-07-29 22:47:48.345 Info HttpServer: HTTP OPTIONS http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.345 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 0ms. http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1
2019-07-29 22:47:48.417 Info HttpServer: HTTP POST http://192.168.0.12:8096/emby/Sessions/Playing/Stopped. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.418 Info App: ProcessRun 'StreamTranscode b7b377': Stopping ffmpeg process with q command for /tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a000.ts
2019-07-29 22:47:48.430 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.431 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 2ms. http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1
2019-07-29 22:47:48.443 Info App: ProcessRun 'StreamTranscode b7b377' Process exited with code 0
2019-07-29 22:47:48.443 Info App: FFMpeg exited with code 0
2019-07-29 22:47:48.443 Info App: Deleting partial stream file(s) /tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8
2019-07-29 22:47:48.443 Info SessionManager: Playback stopped reported by app Emby for Chromecast 2.1.0 playing WJLA-HD. Stopped at 131123 ms
2019-07-29 22:47:48.443 Info MediaSourceManager: Live stream native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f consumer count is now 0
2019-07-29 22:47:48.443 Info MediaSourceManager: Closing live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f
2019-07-29 22:47:48.443 Info SharedHttpPipelineSource: Closing SharedHttpPipelineSource
2019-07-29 22:47:48.444 Info HttpServer: HTTP Response 200 to 127.0.0.1. Time: 138497ms. http://127.0.0.1:8096/LiveTv/LiveStreamFiles/32b9c7e4394640469420514ccaf5584b/stream.ts
2019-07-29 22:47:48.446 Info MediaSourceManager: Live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f closed successfully
2019-07-29 22:47:48.446 Info HttpServer: HTTP Response 204 to 192.168.0.65. Time: 29ms. http://192.168.0.12:8096/emby/Sessions/Playing/Stopped
2019-07-29 22:47:48.459 Info SharedHttpPipelineSource: SharedHttpPipelineSource is done streaming.
2019-07-29 22:47:48.459 Info SharedHttpPipelineSource: Deleting temp files /tmp/transcoding-temp/32b9c7e4394640469420514ccaf5584b.ts
2019-07-29 22:47:48.519 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/Items/1387/Images/Backdrop/0?tag=8f13373fc3e32ce9c07d8a3710c9a2c6&quality=80. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
Link to comment
Share on other sites

 

Seeing what I think is the same issue with a Linux Server 4.2.0.36.

 

LiveTV starts, then dies after a few minutes, restarting after that and it's usually OK.

[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8.tmp' for writing
SegmentComplete=video:0 Index=44 Start=132.015222 End=135.001544 Duration=2.986322 offset_pts=0 start_pts=132015222 Frames=179 filename=hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0044.ts
[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a0045.ts.tmp' for writing
elapsed=00:02:12.24 frame= 8146 fps= 62 q=-0.0 size=  134805kB time=00:02:15.83 bitrate=8129.8kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:12.74 frame= 8181 fps= 62 q=-0.0 size=  135353kB time=00:02:16.41 bitrate=8128.0kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:13.25 frame= 8211 fps= 62 q=-0.0 size=  135851kB time=00:02:16.92 bitrate=8128.0kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:13.75 frame= 8238 fps= 62 q=-0.0 size=  136286kB time=00:02:17.37 bitrate=8127.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:14.25 frame= 8265 fps= 62 q=-0.0 size=  136636kB time=00:02:17.82 bitrate=8121.5kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:14.75 frame= 8295 fps= 62 q=-0.0 size=  137263kB time=00:02:18.32 bitrate=8129.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8.tmp' for writing
SegmentComplete=video:0 Index=45 Start=135.001533 End=138.004544 Duration=3.003011 offset_pts=0 start_pts=135001533 Frames=180 filename=hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0045.ts
[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a0046.ts.tmp' for writing
elapsed=00:02:15.25 frame= 8322 fps= 62 q=-0.0 size=  137710kB time=00:02:18.77 bitrate=8129.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
elapsed=00:02:15.85 frame= 8355 fps= 61 q=-0.0 size=  138198kB time=00:02:19.32 bitrate=8125.9kbits/s dup=86 drop=0 throttle=off speed=1.03x    

[q] command received. Exiting.

[segment @ 0x15de9c0] Opening '/tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8.tmp' for writing
SegmentComplete=video:0 Index=46 Start=138.004533 End=139.756289 Duration=1.751756 offset_pts=0 start_pts=138004533 Frames=105 filename=hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0046.ts
elapsed=00:02:16.16 frame= 8377 fps= 62 q=-0.0 Lsize=  138534kB time=00:02:19.72 bitrate=8122.3kbits/s dup=86 drop=0 throttle=off speed=1.03x    
video:135256kB audio:3278kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
T=5.126s
Local Time: 22:47:48
[aac @ 0x16cc2c0] Qavg: 194.981

and

2019-07-29 22:47:45.464 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/videos/299232/live.m3u8?DeviceId=VHJpYW5nbGUgVFY1&MediaSourceId=native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&PlaySessionId=c39c048bf93e46ecaa64dc094848b35d&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&VideoCodec=h264&AudioCodec=aac,mp3&VideoBitrate=139616000&AudioBitrate=384000&MaxWidth=1920&AudioStreamIndex=-1&TranscodingMaxAudioChannels=6&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&h264-profile=high,main,baseline,constrainedbaseline&h264-level=42&aac-audiochannels=2&TranscodeReasons=ContainerNotSupported. Host=192.168.0.12:8096, Connection=keep-alive, Origin=https://mediabrowser.github.io, User-Agent=Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768, Accept=*/*, Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.9, CAST-DEVICE-CAPABILITIES={"bluetooth_supported":false,"display_supported":true,"hi_res_audio_supported":false,"remote_control_input_supported":false,"touch_input_supported":false}
2019-07-29 22:47:45.465 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 1ms. http://192.168.0.12:8096/emby/videos/299232/live.m3u8?DeviceId=VHJpYW5nbGUgVFY1&MediaSourceId=native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&PlaySessionId=c39c048bf93e46ecaa64dc094848b35d&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f&VideoCodec=h264&AudioCodec=aac,mp3&VideoBitrate=139616000&AudioBitrate=384000&MaxWidth=1920&AudioStreamIndex=-1&TranscodingMaxAudioChannels=6&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&h264-profile=high,main,baseline,constrainedbaseline&h264-level=42&aac-audiochannels=2&TranscodeReasons=ContainerNotSupported
2019-07-29 22:47:45.743 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/videos/299232/hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0044.ts. Host=192.168.0.12:8096, Connection=keep-alive, Origin=https://mediabrowser.github.io, User-Agent=Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768, Accept=*/*, Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.9, CAST-DEVICE-CAPABILITIES={"bluetooth_supported":false,"display_supported":true,"hi_res_audio_supported":false,"remote_control_input_supported":false,"touch_input_supported":false}
2019-07-29 22:47:46.561 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 819ms. http://192.168.0.12:8096/emby/videos/299232/hls/b6806e20631a3ecaeb4c3fdb1f4a0a00/b6806e20631a3ecaeb4c3fdb1f4a0a0044.ts
2019-07-29 22:47:48.342 Info HttpServer: HTTP OPTIONS http://192.168.0.12:8096/emby/Sessions/Playing/Stopped. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.343 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 0ms. http://192.168.0.12:8096/emby/Sessions/Playing/Stopped
2019-07-29 22:47:48.345 Info HttpServer: HTTP OPTIONS http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.345 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 0ms. http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1
2019-07-29 22:47:48.417 Info HttpServer: HTTP POST http://192.168.0.12:8096/emby/Sessions/Playing/Stopped. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.418 Info App: ProcessRun 'StreamTranscode b7b377': Stopping ffmpeg process with q command for /tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a000.ts
2019-07-29 22:47:48.430 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768
2019-07-29 22:47:48.431 Info HttpServer: HTTP Response 200 to 192.168.0.65. Time: 2ms. http://192.168.0.12:8096/emby/Users/50386be425754b5faa6385760741e8fa/Items?SortBy=Random&IncludeItemTypes=Movie%2CSeries&ImageTypes=Backdrop&Recursive=true&MaxOfficialRating=PG-13&HasOfficialRating=true&Limit=1
2019-07-29 22:47:48.443 Info App: ProcessRun 'StreamTranscode b7b377' Process exited with code 0
2019-07-29 22:47:48.443 Info App: FFMpeg exited with code 0
2019-07-29 22:47:48.443 Info App: Deleting partial stream file(s) /tmp/transcoding-temp/b6806e20631a3ecaeb4c3fdb1f4a0a00.m3u8
2019-07-29 22:47:48.443 Info SessionManager: Playback stopped reported by app Emby for Chromecast 2.1.0 playing WJLA-HD. Stopped at 131123 ms
2019-07-29 22:47:48.443 Info MediaSourceManager: Live stream native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f consumer count is now 0
2019-07-29 22:47:48.443 Info MediaSourceManager: Closing live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f
2019-07-29 22:47:48.443 Info SharedHttpPipelineSource: Closing SharedHttpPipelineSource
2019-07-29 22:47:48.444 Info HttpServer: HTTP Response 200 to 127.0.0.1. Time: 138497ms. http://127.0.0.1:8096/LiveTv/LiveStreamFiles/32b9c7e4394640469420514ccaf5584b/stream.ts
2019-07-29 22:47:48.446 Info MediaSourceManager: Live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_native_9098a73d5f0a41a094a99f31435d5a51_890c3f51fb44f76764f82074b0e9c98f closed successfully
2019-07-29 22:47:48.446 Info HttpServer: HTTP Response 204 to 192.168.0.65. Time: 29ms. http://192.168.0.12:8096/emby/Sessions/Playing/Stopped
2019-07-29 22:47:48.459 Info SharedHttpPipelineSource: SharedHttpPipelineSource is done streaming.
2019-07-29 22:47:48.459 Info SharedHttpPipelineSource: Deleting temp files /tmp/transcoding-temp/32b9c7e4394640469420514ccaf5584b.ts
2019-07-29 22:47:48.519 Info HttpServer: HTTP GET http://192.168.0.12:8096/emby/Items/1387/Images/Backdrop/0?tag=8f13373fc3e32ce9c07d8a3710c9a2c6&quality=80. UserAgent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.157768

 

Hi there @@osealion, please attach the complete emby server and ffmpeg logs. thanks !

Link to comment
Share on other sites

  • 3 weeks later...

@@osealion, as a test, if you disable hardware acceleration on the server, does that make a difference? Or that might render you unable to test if the server can't transcode fast enough with the CPU.

Link to comment
Share on other sites

osealion

So far so good with the HW accel disabled. 

 

No random stopping of the LiveTV steam.

 

I've got a beefy CPU so the usage isn't toooooo bad.

 

I'm running Emby in a docker container on a Clear Linux host.

 

Let me know if there's any other diagnostic info that would help.

 

 

Thanks!

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
×
×
  • Create New...