Closed jrbski closed 4 years ago
I think @thornbill said there’s good success if you try turning on VLC in the settings. I don’t remember if you have to have it installed as well, or if we bundle it.
Enabling VLC in the AndroidTV app does allow the stream to work correctly. I did confirm that I do not have the VLC app installed on my FireTV, so it appears to be bundled in (at least in the v0.9 app).
Thanks for the suggestion @anthonylavado !
As a note, I have found I need to offset the sound by -200 or -300 for the sound to be sync'd to video using VLC. It looks like VLC may have been enabled by default in Beta5... Now that I enabled VLC, the controls are the same as I was using in Beta5.
I'm experiencing the same issue on Android phone. Would a better fix be to have the server transcode the stream for the clients?
I'm experiencing the same issue on Android phone. Would a better fix be to have the server transcode the stream for the clients?
@Artiume Android phone is structured differently, but there’s work going on there for a better player.
Cool. I did some digging and found this. This was what I was thinking as a server side solution.
This, #1202 and PR #2160 for the server look interesting to me.
With Android liveTV often throws an error about unsupported stream, casting to a chromecast often just results in a Black screen.
The same channel will often play in chrome on the same device if I go via the web-ui.
Yeah I have the same issue and I did PR #2160 to try and fix it but transcoding live streams is broken for Android and AndroidTV so no channels work lol.
@anthonylavado The issue with ffmpeg, I compared the two logs and the failing ffmpeg build didn't pass any bitrate, the successful one used "BitRate":2000000 Would that fall on ffprobe or ffmpeg? I couldn't find anything else wrong.
In the app settings for Android TV have you tried enabling VLC in the live tv section? That seems to do the trick for me. This was the default at one point. We should probably change that back.
Hey Bill, testing VLC mode with PR #2160 enabled doesn't seem to work. I think it's because VLC should allow for directplay but the PR (if enabled for the user) will enforce transcoding and breaks the stream, even for VLC. I'm gonna post what I've found. This should probably go under its appropriate Android ticket and not this one, but I imagine the ffmpeg issue between Android and Android TV have the same root cause since they're both wrappers and it's easier for me to troubleshoot with my mobile device. Comparing the logs, Android w/ Chrome will maintain the stream as an m3u8 and continues to use .ts segments whereas the Android App attempts to create an mkv container.
Android with Chrome
http://domain.com/videos/32204-717d-a4a6-684a-75523db/live.m3u8?DeviceId=TW96a81LjAgKExpbnV4OyB2lkIDguMC4wOyBHOTMwUCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSNTCwgbGlrZSBHZWNrbQ2hyb21lLzc4LjAuMzkwNC4xMDggTW9iaWxlIFNhZmFyaS81MzcuMzZ8MTDU1NTgwNDQ3Mw11&MediaSourceId=2be21c2561862a97edf0be4db&VideoCodec=h264&AudioCodec=mp3,aac&AudioStreamIndex=-1&VideoBitrate=8000000&AudioBitrate=135750&PlaySessionId=464a9621b4254200befa7439121eaf76&LiveStreamId=a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_2be21c256186162a936a407edf0be4db&TranscodingMaxAudioChannels=2&RequireAvc=false&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=False&h264-profile=high,main,baseline,constrainedbaseline,high10&h264-level=51&TranscodeReasons=ContainerNotSupported,VideoCodecNotSupported,AudioCodecNotSupported&allowVideoStreamCopy=false&allowAudioStreamCopy=false
Android App
http://domain.com/videos/3212c717d-a4a6-684a-7505fe0523db/stream.mkv?DeviceId=60de542cb23644&MediaSourceId=2be21c25618936a407edf0be4db&VideoCodec=h264,vp8,vp9&AudioCodec=mp3,aac,opus,flac,vorbis&AudioStreamIndex=-1&VideoBitrate=8000000&AudioBitrate=135750&PlaySessionId=c07689192b4e4c98a61bb1f452972b88&LiveStreamId=a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_2be21c256186162a936a407edf0be4db&TranscodingMaxAudioChannels=2&CopyTimestamps=true&RequireAvc=false&h264-profile=high,main,baseline,constrainedbaseline&h264-level=41&TranscodeReasons=ContainerBitrateExceedsLimit&allowVideoStreamCopy=false&allowAudioStreamCopy=false
Another part I found interesting is this is missing from the Android App. &TranscodeReasons=ContainerNotSupported,VideoCodecNotSupported,AudioCodecNotSupported&
I'm used to this tag showing up in every Live Stream because of PR #2160.
This is another odd bit for the Android App stream.
No Limit is set, so I'm not sure where this is cropping up from
&TranscodeReasons=ContainerBitrateExceedsLimit
Looking inside MediaBrowser.Model/Session/TranscodingInfo.cs, i've found this
public enum TranscodeReason
{
ContainerNotSupported = 0,
VideoCodecNotSupported = 1,
AudioCodecNotSupported = 2,
ContainerBitrateExceedsLimit = 3,
What if the transcode reason logic is summing their return values instead of properly segregating them? Only thing I can think of for the bitrate exceeding flag to be thrown like that.
Copy Timestamps is also inside the app stream only, but I'm not sure if it's an issue or not
&CopyTimestamps=true&
If the Android app and TV app are truly different, I'll post only ATV results from now on :) .
I can't test it until I have access to my fire stick but I was able to fix the live tv stream on android by substituting .ts for .mkv in the ffmpeg command. I'll start digging in the code in the stream builder to see what I can find
Edit: Comparing my issue to the original issue, I think I hijacked this thread.
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or master branch, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label. This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.
Describe the bug
When trying to stream livetv from an HDhomerun using Jellyfin 10.3.7 to AndroidTV app v0.9 sideloaded on an Amazon FireTV, a number of channels fail to stream, and a message stating "Error streaming live tv..." appears, and the app repeatedly retries the stream.
In looking into log,and testing different channels, it appears that 16:9 streams have no issues, but 4:3 streams fail. All channels work properly using Chrome on a windows laptop, and an iPad using Safari.
To Reproduce
Expected behavior
All channels stream to FireTV
Logs
Successful channel logs:
Failed Channel Logs:
Screenshots
System (please complete the following information):
Additional context
I had also been testing Beta5 of the Android app, and did not see similar errors streaming HDhomerun channels in that version of the app.