[Android MiniClient] Now in BETA

[nyplayer]

Originally Posted by stuckless

Does anyone know what version of Android they are running on the Nexus Player? I'm wondering if this is somehow related to something in the android version that I might have accidentally included. I'm running 6.0 on everything, and it run on my phone and shield tv.

I am running 6.0.1

[stuckless]

Originally Posted by nyplayer

Using EXOPLAYER and the soon to be released Beta OPenDCT I am able to play all formats on this miniclient.... I can pause and Seek liveTV.
IJKPLAYER appears to crash on my 720P H.264 TS files.

If you need a sample of 720p H.264 file let me know.

Originally Posted by nyplayer

I am running 6.0.1

If this is the latest RC3 or 4, then I suspect it's same issue as everyone else I did download your file and I was able to play it fine on my phone and TV. I'd recommend going back to RC2 until this is resolved.

[cncb]

Originally Posted by stuckless

Stateful remote only works against a V9 server, but even then, it's not 100%. Basically I'm having to "guess" about the media state, provided that sagetv is sending me the hints (which is does in V9). It;s because of this that I added the "enable" stateful remote action in the on screen navigation.

Skipping while paused will probably never work (at least not, doesing a frame-by-frame skip).

This is with a V9 server and worked before so I'm not sure what changed.

I'm interested in a normal skip ahead/back while paused rather than frame-by-frame so hopefully this will be possible.

[nyplayer]

Originally Posted by stuckless

If this is the latest RC3 or 4, then I suspect it's same issue as everyone else I did download your file and I was able to play it fine on my phone and TV. I'd recommend going back to RC2 until this is resolved.

Everthing plays great using EXOPLayer so not sure I want to go back....

[dinki]

Seems I can't write to the default log location fit some reason. I see the error when I select send log option . the regular option doesn't produce any file so I'm guessing it's permissions problem for that one too. I guess I sent you an old log file. I deleted that one but still can't write the new one.

[EnterNoEscape]

I noticed some combing when I watched a raw 720p60 H.264 clip from Comcast which implies their progressive streams have some kind of progressive/interlaced hybrid thing going on. Also Windows thinks a 1 minute file is two minutes after the latest OpenDCT remuxes it and if you use the ffmpeg program to remux the file it becomes over 24 minutes according to Windows.

Transcoding it to the same format results in playback still not working correctly. Transcoding with deinterlacing (yadif=0) however results in a file that will playback correctly. This tells me that there are clearly some time base problems with at least the video stream that the deinterlace filter is able to sort out. MPC-HC gets all the of details correct in all of these scenarios. I suspect the abnormal nature of these streams is likely why they will not play back everywhere consistently.

Update: This is not completely correct: I figured it out. The Comcast streams have redundant frames with the same PTS. Some hardware codecs know to just skip them, but the Fire TV and the Nexus apparently try to decode every single frame and because they are trying to maintain a constant framerate, it just slows the video down throwing everything out of sync and in some cases crashing the player.

Update2: The presentation time stamps are out of order in these streams and it looks like the difference between 1080i and 720p is that 1080i only sends at most 1 out of order PTS in a row and 720p sends up to 4 in a row. Removing the out of order frames from the 720p stream appears to fix it and I can't tell the difference from the raw copy. The frames being removed in 720p look like they are all B frames. It is apparently normal for them to be out of order. As I understand it, the decoder is supposed to be able to figure this out and put them in the correct order, but that's not happening.

Could this be a buffering issue with the mini client?

[ptzink]

Stuckless, the new laucher UI looks great! Thanks for the update. Now I just need audio passthrough somehow...

[stuckless]

Originally Posted by EnterNoEscape

I noticed some combing when I watched a raw 720p60 H.264 clip from Comcast which implies their progressive streams have some kind of progressive/interlaced hybrid thing going on. Also Windows thinks a 1 minute file is two minutes after the latest OpenDCT remuxes it and if you use the ffmpeg program to remux the file it becomes over 24 minutes according to Windows.

Transcoding it to the same format results in playback still not working correctly. Transcoding with deinterlacing (yadif=0) however results in a file that will playback correctly. This tells me that there are clearly some time base problems with at least the video stream that the deinterlace filter is able to sort out. MPC-HC gets all the of details correct in all of these scenarios. I suspect the abnormal nature of these streams is likely why they will not play back everywhere consistently.

Update: This is not completely correct: I figured it out. The Comcast streams have redundant frames with the same PTS. Some hardware codecs know to just skip them, but the Fire TV and the Nexus apparently try to decode every single frame and because they are trying to maintain a constant framerate, it just slows the video down throwing everything out of sync and in some cases crashing the player.

Update2: The presentation time stamps are out of order in these streams and it looks like the difference between 1080i and 720p is that 1080i only sends at most 1 out of order PTS in a row and 720p sends up to 4 in a row. Removing the out of order frames from the 720p stream appears to fix it and I can't tell the difference from the raw copy. The frames being removed in 720p look like they are all B frames. It is apparently normal for them to be out of order. As I understand it, the decoder is supposed to be able to figure this out and put them in the correct order, but that's not happening.

Could this be a buffering issue with the mini client?

Does this happen in both players? I do buffer the data coming from the server, but I don't buffer "frames". That is handled at the player level. This is using ffplay as the player, mayber there is a "ff" option I can pass to the the player??

Originally Posted by ptzink

Stuckless, the new laucher UI looks great! Thanks for the update. Now I just need audio passthrough somehow...

Thanks... I think this is a better UI for the TV mode... too bad it breaks the player, somehow

[stuckless]

I hooked up my Nexus Player (ADT-1) (developer edition) and ran though a bunch of files... they all played fine... which is good for me, but I was hoping that it would crash so I could look at the log and see why it's failing.

My ADT-1 is running Android 5.0... and it's the ARM version. So, this could sill be an x86 issue, I just can't test it

I might have to go ahead and order a standard Nexus Player if we can't get log files for this.

I tested this using the Phone Version on an x86 emulator, and it could play the videos as well. The Phone/TV versions are still the same, just they have different startup screens.

Not sure what else to test/try on my end.

[dinki]

I will certainly provide logs but not sure why I'm getting permissions issues. Any idea on a fix or way to change where it is written?

[stuckless]

Originally Posted by dinki

I will certainly provide logs but not sure why I'm getting permissions issues. Any idea on a fix or way to change where it is written?

Android 4.4+ changed the external sd permissions so that apps can't write directly to it There are work arounds, but it's little complicated for something like this. This is why I moved to SendLog but it has its own problems

[EnterNoEscape]

Originally Posted by stuckless

Does this happen in both players? I do buffer the data coming from the server, but I don't buffer "frames". That is handled at the player level. This is using ffplay as the player, mayber there is a "ff" option I can pass to the the player??

Sorry, I should have mentioned what I'm using.

Using ijkplayer, with the B frames in place the playback is very slow. I noticed that when I skip, the time code is correct and the video is in sync for a fraction of a second. The same stream put through VideoRedo has the same playback issues and is unseekable. I tried re-encoding the stream to a very low bitrate and playback of the video was still slower than the audio. Removing the B frames or transcoding and halving the framerate are the only things that make it play correctly.

I can't use ExoPlayer 99% of the time on my Fire TV Stick.

You gave me an idea about ffplay. I tried playing the videos back with ffplay and they were flawless. I suspect it's the hardware codec at fault...I'm not sure what you can do there. Sorry if I missed this earlier in the thread, but is there a way to turn off the hardware acceleration for testing?

[Jabroni]

I think i found whats causing the issue

03-07 19:57:19.040  3397  3397 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: /data/app/sagex.miniclient.android.tv-1/lib/x86/libijkffmpeg.so: has text relocations

I'll pm you the link of the full log file in case u want to take a look of it

*Update*

Seems like a ijkplayer / ffmpeg bug which was fixed 13 days ago??
https://github.com/Bilibili/ijkplayer/pull/953

[EnterNoEscape]

Using ijkplayer, on the Fire TV Stick appears to have this video slow down problem with MPEG-2 60fps content too. 1080i 29.97 MPEG-2 doesn't have any issues that I can find. So something about that extra 30fps is causing problems.

[stuckless]

Originally Posted by EnterNoEscape

is there a way to turn off the hardware acceleration for testing?

I used to have an option to disable it, but then I didn't see the point, so I removed it. And for ExoPlayer, you can't disable it, since without hardware decoders, nothing will play.

Originally Posted by Jabroni

I think i found whats causing the issue

03-07 19:57:19.040  3397  3397 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: /data/app/sagex.miniclient.android.tv-1/lib/x86/libijkffmpeg.so: has text relocations

Seems like a ijkplayer / ffmpeg bug which was fixed 13 days ago??
https://github.com/Bilibili/ijkplayer/pull/953

I will pull in a new IJKPlayer build this weekend and push out another RC.

Originally Posted by EnterNoEscape

Using ijkplayer, on the Fire TV Stick appears to have this video slow down problem with MPEG-2 60fps content too. 1080i 29.97 MPEG-2 doesn't have any issues that I can find. So something about that extra 30fps is causing problems.

Could I get a small sample 50-100mb of a 60fps file.

[RayGannon]

I have the "Exit to Home Screen" option selected but when I exit Sage it takes me back to the server selection screen. I'm running RC-4 on a ShieldTV with Android 6. Is this a know issue ?

[stuckless]

Originally Posted by RayGannon

I have the "Exit to Home Screen" option selected but when I exit Sage it takes me back to the server selection screen. I'm running RC-4 on a ShieldTV with Android 6. Is this a know issue ?

Open an issue. I think it's a result of the changes made for the specific Android TV front end.

[Monedeath]

Originally Posted by stuckless

Android 4.4+ changed the external sd permissions so that apps can't write directly to it There are work arounds, but it's little complicated for something like this. This is why I moved to SendLog but it has its own problems

Yeah, discovered that a couple weeks ago, haven't bothered to see how Google pitched that change as a feature for end users vs being a money grab for device makers by making it near impossible to work around the storage limitations of the device as sold vs the microsd slot.

[RayGannon]

Originally Posted by stuckless

Open an issue.

Opened as issue #83. That went a LOT easier than I thought it would.

I've been away from SageTV for a long time. The android client and the linux based server were the pieces I needed to get back into it. After a great deal of reading ahead of time it took a little more than an hour to go from bare metal to a working server and client thanks to the fine people on this forum. It's been a bit of a re-learning curve but it's all working great at the moment.

[stuckless]

Originally Posted by Monedeath

Yeah, discovered that a couple weeks ago, haven't bothered to see how Google pitched that change as a feature for end users vs being a money grab for device makers by making it near impossible to work around the storage limitations of the device as sold vs the microsd slot.

Basically they pitched it as a "feature". Previously the SDCARD was free storage for anyone to read/write (with permissions). The problem, from their perspective was that it was insecure, since App A could read and write the same files as App B. Now, the CD card is like the internal storage (you get a specific dir to read/write), and if you need to do something more witht he SD card, then you use the "Storage Access Framework", another poorly designed and crapily implemented file system api that looks nothing like any other file system api on the planet Well done.

Originally Posted by RayGannon

Opened as issue #83. That went a LOT easier than I thought it would.

I've been away from SageTV for a long time. The android client and the linux based server were the pieces I needed to get back into it. After a great deal of reading ahead of time it took a little more than an hour to go from bare metal to a working server and client thanks to the fine people on this forum. It's been a bit of a re-learning curve but it's all working great at the moment.

That's good to know. Hopefully over time, the installers will get better, the documentation will get better, and that upfront time cost will drop from hours to minutes... hopefully