[Android MiniClient] Now in BETA

[samgreco]

I am wired. to the same switch that my PC client and HD200 are. And the video file was an H.264 in an MKV container. At least I'm pretty sure it was. I'll fire it up later and doule check that.

I had just loaded Beta 8.

[stuckless]

Originally Posted by samgreco

I am wired. to the same switch that my PC client and HD200 are. And the video file was an H.264 in an MKV container. At least I'm pretty sure it was. I'll fire it up later and doule check that.

I had just loaded Beta 8.

In the preferences as well, you can turn on a debug option to to show a message when a software encoder is in use. I'd turn that on, and see if software encoders are being used. (I use it a lot for testing)

[stuckless]

Originally Posted by Fuzzy

Interestingly, I think the HD-300 actually goes into standby when the exit command is used, but I don't think it does when the network connection is pulled - Guess I'd have to check on that to make sure.

Isn't there a standby and an exit in the Exit menu?

[stuckless]

Originally Posted by gexi

Will do, I was hoping to add it myself but it definitely was not as easy as it sounded.

In Beta 9 there is now an option to exit to the home screen when sagetv exits (enabled by default)

[stuckless]

Originally Posted by samgreco

I am wired. to the same switch that my PC client and HD200 are. And the video file was an H.264 in an MKV container. At least I'm pretty sure it was. I'll fire it up later and doule check that.

I had just loaded Beta 8.

So I fired this up on my FireTV (WIFI) and I do see some sluggishness. Interestingly enough, on the ShieldTV I don't have any sluggishness in the Gemstone UI. I appears to run faster than the HD300. Now this isn't a fair test since, my FireTV is WIFI and not wired, but, maybe there is a bit of lag in there, even on WIRED. I thought that once the FireTV has cached the bitmaps it would speed up... and it did, but not to point where I see it on the ShieldTV.

That being said.. h264 in a MKV container should play just fine. I did try a few shows (mostly h264 ts files) and they played fine on the FireTV.

[KryptoNyte]

An HD300 connected via this wifi device;

http://www.amazon.com/NETGEAR-AC750-.../dp/B00HHRP11C

also experiences significant sluggishness. The router is less than 30 feet away.

[stuckless]

Originally Posted by KryptoNyte

An HD300 connected via this wifi device;

http://www.amazon.com/NETGEAR-AC750-.../dp/B00HHRP11C

also experiences significant sluggishness. The router is less than 30 feet away.

Yeah, I'll have to hook my FireTV using ethernet and see what happens. I have a switch 3 feet away, I was just lazy when I setup the FireTV

[samgreco]

Originally Posted by stuckless

So I fired this up on my FireTV (WIFI) and I do see some sluggishness. Interestingly enough, on the ShieldTV I don't have any sluggishness in the Gemstone UI. I appears to run faster than the HD300. Now this isn't a fair test since, my FireTV is WIFI and not wired, but, maybe there is a bit of lag in there, even on WIRED. I thought that once the FireTV has cached the bitmaps it would speed up... and it did, but not to point where I see it on the ShieldTV.

That being said.. h264 in a MKV container should play just fine. I did try a few shows (mostly h264 ts files) and they played fine on the FireTV.

Just checked it and H.264 seems to be fine. It was an MPEG2 .TS file that was having issues.

Also, the overlays seem to be wonky. To the point where they cannot be read at all. I just get part of the left and bottom of the popup. So I can't really change any settings once in the client. I'll try to get an image of it later.

[stuckless]

Originally Posted by samgreco

Just checked it and H.264 seems to be fine. It was an MPEG2 .TS file that was having issues.

Also, the overlays seem to be wonky. To the point where they cannot be read at all. I just get part of the left and bottom of the popup. So I can't really change any settings once in the client. I'll try to get an image of it later.

What overlays? Did you run the configuration wizard on start (It should have walked you through the process, where you set the top/left and bottom/right overscan areas. If that didn't happen then I'd re-run it from the setup menu.

And yeah, MPEG2 TS will use software decoding if using the IJKPlayer (the default) but if you change to ExoPlayer it might work, using hardware decoding.

[cncb]

Beta 8 fixes the crashing (NullPointerException) I was getting in the Gemstone "wall flow" views but it now is very slow to redraw and there are various black screen flashes and things being drawn in the wrong location. This is on a wired Shield TV.

Some MKVs seem to fail to play in ExoPlayer (unfortunately, I did not try to play these before so I'm not sure if it is a new issue). It loads up the player, it looks like the OSD timeline jumps to the end, and then it shows a "failed to play" error message. I'm not sure what is special about these MKVs because others with the same codecs (H264 and DTS-HD) play fine. Hopefully the attached log file might help.

Also, do we know if ExoPlayer supports display of PGS (blu-ray) embedded subtitles?

[stuckless]

Originally Posted by cncb

Beta 8 fixes the crashing (NullPointerException) I was getting in the Gemstone "wall flow" views but it now is very slow to redraw and there are various black screen flashes and things being drawn in the wrong location. This is on a wired Shield TV.

Some MKVs seem to fail to play in ExoPlayer (unfortunately, I did not try to play these before so I'm not sure if it is a new issue). It loads up the player, it looks like the OSD timeline jumps to the end, and then it shows a "failed to play" error message. I'm not sure what is special about these MKVs because others with the same codecs (H264 and DTS-HD) play fine. Hopefully the attached log file might help.

Also, do we know if ExoPlayer supports display of PGS (blu-ray) embedded subtitles?

ExoPlayer is only going to play something, if it can hardware decode the audio and video in the stream. It also means that ExoPlayer has to have the code written to fully parse the various containers and audio/video formats. In your case I see the following error...

ContentCompAlgo 0 not supported

This tells me that that ExoPlayer is not supporting this in its MKV parser. Nothing we can do about this, except sit and wait... or write the necessary code in the MKV parser (which won't happen by me )

As for the wall view... I can't say I've done any testing using it. It's not a view that I'd ever use, personally, since I don't see much value in it. But I suspect that the client is running out of texture memory and has to keep flushing and reloading the textures, which is slow. I'm not sure how wall views operate, but, if they are loading full size images, and then just scaling them down to fit into the small box, then I can see where this would blow the texture memory and cause this sort of thing. From the log, I can see that most of the texture calls return a null texture for the image, and that leads me to believe that while the texture was loaded, the memory got reclaimed before the UI could actually do anything with it. I'll add some extra logging around this, but, to be honest, I'm not sure there'll be much that we can do from the Android Client point of view. Actually there maybe one thing I can co do from the client point of view, it probably will slow down the UI, but, it might result in the UI rendering all of the images.

I don't mind if you open a defect for this... that way I won't forget about it.

[Fuzzy]

Originally Posted by stuckless

ExoPlayer is only going to play something, if it can hardware decode the audio and video in the stream. It also means that ExoPlayer has to have the code written to fully parse the various containers and audio/video formats. In your case I see the following error...

This tells me that that ExoPlayer is not supporting this in its MKV parser. Nothing we can do about this, except sit and wait... or write the necessary code in the MKV parser (which won't happen by me )

Or have it remuxed/transcoded if needed on the server.

Originally Posted by stuckless

As for the wall view... I can't say I've done any testing using it. It's not a view that I'd ever use, personally, since I don't see much value in it. But I suspect that the client is running out of texture memory and has to keep flushing and reloading the textures, which is slow. I'm not sure how wall views operate, but, if they are loading full size images, and then just scaling them down to fit into the small box, then I can see where this would blow the texture memory and cause this sort of thing. From the log, I can see that most of the texture calls return a null texture for the image, and that leads me to believe that while the texture was loaded, the memory got reclaimed before the UI could actually do anything with it. I'll add some extra logging around this, but, to be honest, I'm not sure there'll be much that we can do from the Android Client point of view. Actually there maybe one thing I can co do from the client point of view, it probably will slow down the UI, but, it might result in the UI rendering all of the images.

I don't mind if you open a defect for this... that way I won't forget about it.

This can probably be greatly improved by changing the image caching to work with smaller resolution images. I don't know, however, if gemstone maintains a different cache for each miniclient, or if that is a universal thing.

[stuckless]

Originally Posted by Fuzzy

Or have it remuxed/transcoded if needed on the server.

In this case, i think it would be better to use the IJKPlayer that will handle the stream. But, yes it would be transcoded on the server, but in that case, sagetv tends to send over MPEGPS streams that are not handled by exoplayer, either.

[Fuzzy]

Originally Posted by stuckless

In this case, i think it would be better to use the IJKPlayer that will handle the stream. But, yes it would be transcoded on the server, but in that case, sagetv tends to send over MPEGPS streams that are not handled by exoplayer, either.

Oh, I didn't mean simply changing the capabilities report and using the existing transcoding system. It actually, I believe, is limited to MPEG-PS with MPEG4 video and MP3 audio currently, in SD resolution. The server side transcoding really needs to be looked at, but that sort of depends really on getting a newer ffmpeg built first, and then working on a better system to determine what to transcode and what not to transcode, and what container to put it into based on the player's reported capabilities.

[cncb]

Originally Posted by stuckless

This tells me that that ExoPlayer is not supporting this in its MKV parser. Nothing we can do about this, except sit and wait... or write the necessary code in the MKV parser (which won't happen by me )

It doesn't give any indication what exactly it can't handle? In this case, the files that are failing have H264 video and DTS-HD MA and DTS audio tracks. I have several other files with the same video and audio tracks and they play fine.

Originally Posted by stuckless

As for the wall view... I can't say I've done any testing using it. It's not a view that I'd ever use, personally, since I don't see much value in it. But I suspect that the client is running out of texture memory and has to keep flushing and reloading the textures, which is slow.

Well, I guess the question is how many thumbnails are too many since this could potentially affect any of the thumbnail views/flows in Gemstone. How does the HD300 handle it since the Shield must have more memory?

[tmiranda]

Originally Posted by KryptoNyte

An HD300 connected via this wifi device;

http://www.amazon.com/NETGEAR-AC750-.../dp/B00HHRP11C

also experiences significant sluggishness. The router is less than 30 feet away.

I have two HD300s each connected to one of these via ethernet and it works flawlessly. If you connect wirelessly it's a disaster, the wireless capabilities of the HD300 are really poor.

[stuckless]

Originally Posted by cncb

It doesn't give any indication what exactly it can't handle? In this case, the files that are failing have H264 video and DTS-HD MA and DTS audio tracks. I have several other files with the same video and audio tracks and they play fine.

I suspect that if you run mediainfo on a file that works and a file that doesn't, then it'll be clear, they are not the same.

[/quote]
Well, I guess the question is how many thumbnails are too many since this could potentially affect any of the thumbnail views/flows in Gemstone. How does the HD300 handle it since the Shield must have more memory?[/QUOTE]

Memory is relative. Sure the Shield, as a whole, has more memory, but, SageTV isn't the only thing running on the Shield. And this isn't "memory" so much as a it's texture memory, which is different. The way the things render on the Android TV is different than how it renders on the HD300... as I said, there is possibly a way that I can make this work on the MiniClient. Typically this has nothing to do with how many total thumbnails you have, but instead, how many are visible at any given time, and how large are the thumbnails. In most lists, you see 10 thumbnails... In the wall view, it shows many more, and not sure those images are optimally scaled on the server.

[jusjoken]

Originally Posted by Fuzzy

This can probably be greatly improved by changing the image caching to work with smaller resolution images. I don't know, however, if gemstone maintains a different cache for each miniclient, or if that is a universal thing.

1 cache used in Gemstone for all connected miniclients. Full Clients have their own.

The user can change the size of the cached items in the Image Options screen in Gemstone (under Options from the main menu) but changing those will change them for ALL miniclients connected.

k

[Fuzzy]

Originally Posted by jusjoken

1 cache used in Gemstone for all connected miniclients. Full Clients have their own.

The user can change the size of the cached items in the Image Options screen in Gemstone (under Options from the main menu) but changing those will change them for ALL miniclients connected.

k

That's what I had figured.

[stuckless]

Originally Posted by jusjoken

1 cache used in Gemstone for all connected miniclients. Full Clients have their own.

The user can change the size of the cached items in the Image Options screen in Gemstone (under Options from the main menu) but changing those will change them for ALL miniclients connected.

k

but are the images physically resized to size you need, or are they scaled to the size you need. For example if the poster is 500x1000 but software scales to 50x100... then I'm getting the 500x1000 sized image on the MiniClient and then hardware scaling it. (at least I think that's how the images work )

Either way, I need to check the MiniClient... I'm pretty sure I'm actually holding a reference to ALL image textures as they are send from the sagetv and rendering them in the render loop. ie, it's not a get an image, render and image, and then proceed until there are not images. The reason for this is really that on Android I have to avoid doing work on the UI thread, but this is all UI stuff over the network.. and I can't access network on the UI thread, etc. It can be tricky.