Fork of SageTV MiniClient for Android TV

[jvl711]

Originally Posted by tvmaster2

The key mappings in the MiniClient software, or the SageTV server software? I turned it OFF in the Miniclients Settings menu, or to NONE, but no change in behavior.
Thanks

Yes in the android client is what I was talking about. It seems to be working in Pixel 3xl. I can check on a oneplus 6. I think there might be differences in how the volume rocker registers it's action to android in different hardware.

Could you try the volume keys when the overlay menu is open (the one with the media controls and other action buttons). It might work when that is visible. If it does that might point me in a direction.

[KryptoNyte]

Volume is also working on Samsung Note 20. Key mapping is set to NONE

[tvmaster2]

Originally Posted by jvl711

Yes in the android client is what I was talking about. It seems to be working in Pixel 3xl. I can check on a oneplus 6. I think there might be differences in how the volume rocker registers it's action to android in different hardware.

Could you try the volume keys when the overlay menu is open (the one with the media controls and other action buttons). It might work when that is visible. If it does that might point me in a direction.

Hi. Yes, Samsung S7 volume controls work when the overlay is open. Also, when the overlay ISN’T open, the phone’s volume controls work if other things beside ‘NONE’ are mapped to them, like ‘Up & Down’, just not volume operations. Go figure.
So, that’s kinda good, at least I can turn it down now as long as the overlay is up. thanks

[davidk21770]

Originally Posted by tvmaster2

The key mappings in the MiniClient software, or the SageTV server software? I turned it OFF in the Miniclients Settings menu, or to NONE, but no change in behavior.
Thanks

Oops...
I realized that it's been a while since I tried just using the buttons and found that they are working just fine! I do not need to swip-down the android's quick menu to make them work.
Sorry for any confusion .

[gexi]

With the latest 1.7.1 version on a firetv stick and firetv integrated tv I seem to be getting a lot of exo2player errors on files that used to work. Mostly mkv and certain avi files. Is there a place I can download the 1.7.0 version to see if it is something that happened with the upgrade vs my machine?

[thopkin1]

I am also seeing the exoplayer errors with version 1.7.1 that I didn't see in version 1.7.0. I am also using the transcoding plug-in and while it worked great with 1.7.0 it seems since the upgrade to 1.7.1 it has problems when programs change (meaning one show ends and the next begins without changing channels). Often the show just stops/freezes and I have to stop it and retune the channel to get it playing again. Would be happy to help debug or install 1.7.0 if I can a copy of it. Thanks!

[jvl711]

Hi All,

I might need to post this in the GitHub area, but I wanted to see what you guys are seeing.

I am working on trying to develop the "Stream Fix" for the Android Client. To accomplish that I am using the SageTVTranscoder to do a remux of the file into a new container without reencoding the audio or video. This is working well, but I think I may have possibly identified a bug in Sage.

When SageTV is using the SageTVTranscoder to transcode (Fixed/Dynamic/Low Bandwidth) livetv streams, when the program is over and it switches to the next program it freezes, and is not able to transition to the next file. The timebar keeps ticking up, but the video/audio are frozen. SageTV shows some logs that indicate that it is trying to switch, but I am not sure where the issue might be. I would like to know if you guys are all seeing the same behavior, and it this is a known issue. And if so, if anyone knows where I might look to fix it.

I hesitant to move forward with the "Steam Fix" if this issue is real. I feel like it would be to big of a step backwards.

Thanks for your input.

Josh

[jvl711]

Originally Posted by thopkin1

I am also seeing the exoplayer errors with version 1.7.1 that I didn't see in version 1.7.0. I am also using the transcoding plug-in and while it worked great with 1.7.0 it seems since the upgrade to 1.7.1 it has problems when programs change (meaning one show ends and the next begins without changing channels). Often the show just stops/freezes and I have to stop it and retune the channel to get it playing again. Would be happy to help debug or install 1.7.0 if I can a copy of it. Thanks!

I just saw this after I posted my post. Are you sure this was working? My testing is showing this as a core SageTV issue. Maybe I am wrong.

Josh

[jvl711]

Originally Posted by gexi

With the latest 1.7.1 version on a firetv stick and firetv integrated tv I seem to be getting a lot of exo2player errors on files that used to work. Mostly mkv and certain avi files. Is there a place I can download the 1.7.0 version to see if it is something that happened with the upgrade vs my machine?

Older versions are available in GitHub to sideload.

FYI, avi files were not supported in ExoPlayer. I changed the config to tell SageTV that ExoPlayer does not support AVI so that it could be transcoded. If you are using Dynamic streaming mode your millage may vary.

Josh

[wnjj]

Originally Posted by jvl711

Hi All,

I might need to post this in the GitHub area, but I wanted to see what you guys are seeing.

I am working on trying to develop the "Stream Fix" for the Android Client. To accomplish that I am using the SageTVTranscoder to do a remux of the file into a new container without reencoding the audio or video. This is working well, but I think I may have possibly identified a bug in Sage.

When SageTV is using the SageTVTranscoder to transcode (Fixed/Dynamic/Low Bandwidth) livetv streams, when the program is over and it switches to the next program it freezes, and is not able to transition to the next file. The timebar keeps ticking up, but the video/audio are frozen. SageTV shows some logs that indicate that it is trying to switch, but I am not sure where the issue might be. I would like to know if you guys are all seeing the same behavior, and it this is a known issue. And if so, if anyone knows where I might look to fix it.

I hesitant to move forward with the "Steam Fix" if this issue is real. I feel like it would be to big of a step backwards.

Thanks for your input.

Josh

The file/show switchover code is in Seeker.java. There is also the concept of fast mux switch on capture devices that can change the file name without stopping and restarting. Prehaps that is causing your issue? If you look through the log file you should see what type of switch it was doing. I spent some time in this area with a bug involving file time stamps so may be able to help you some.

The setting to turn off fast switch is “seeker/fast_mux_switch=false” in case that helps.

[nyplayer]

Originally Posted by wnjj

The file/show switchover code is in Seeker.java. There is also the concept of fast mux switch on capture devices that can change the file name without stopping and restarting. Prehaps that is causing your issue? If you look through the log file you should see what type of switch it was doing. I spent some time in this area with a bug involving file time stamps so may be able to help you some.

The setting to turn off fast switch is “seeker/fast_mux_switch=false” in case that helps.

Cause this be causing a playlist not to play the next file ... I seem to be having this problem ... of playlist stopping at the end of the first show.

[jvl711]

Originally Posted by wnjj

The file/show switchover code is in Seeker.java. There is also the concept of fast mux switch on capture devices that can change the file name without stopping and restarting. Prehaps that is causing your issue? If you look through the log file you should see what type of switch it was doing. I spent some time in this area with a bug involving file time stamps so may be able to help you some.

The setting to turn off fast switch is “seeker/fast_mux_switch=false” in case that helps.

I think you hit the nail right on the head here. I did not do a ton of testing yet, but it seems with fast_mux_switch=true it freezes. If I have it = false it seems to work some of the time. I am not sure where I need to go with this. I might need to do a lot more code review and debug to understand what is going on.

I can post some logs if you think you might be able to help.

Thanks,
Josh

[wnjj]

Originally Posted by nyplayer

Cause this be causing a playlist not to play the next file ... I seem to be having this problem ... of playlist stopping at the end of the first show.

I’m not sure but I think fast mux switching is only for live TV. Without fast mux mode, there’s a slight delay/freeze when the show changes to the next one.

[wnjj]

Originally Posted by jvl711

I think you hit the nail right on the head here. I did not do a ton of testing yet, but it seems with fast_mux_switch=true it freezes. If I have it = false it seems to work some of the time. I am not sure where I need to go with this. I might need to do a lot more code review and debug to understand what is going on.

I can post some logs if you think you might be able to help.

Thanks,
Josh

It couldn’t hurt to post some if I find the time. If it’s gets too messy we can move to email.

[jvl711]

Originally Posted by wnjj

It couldn’t hurt to post some if I find the time. If it’s gets too messy we can move to email.

So, with fast_mux_switching = false and some minor code changes to the client I have been able to get this to work well.

The two below actions seem critical to the switch over to the new stream. the pusher thread needs to tell the client that there is no more data, than the client needs to tell the server it has no more data. This was not happening consistently.

Sat 2/20 10:45:00.344 [Pusher@7d1ee92e] Pushing EOS to decoder-1
Sat 2/20 10:45:00.348 [Pusher@7d1ee92e] Received eos from client

I added some code which I believe is helping this situation. I am able to get consistent stream switches when using the transcoder. I check how much data is available in the buffer, and if it is 0 I send back EOS to the server.

public int getBufferLeft()
    {


        if (dataSource instanceof HasPushBuffer)
        {
            if (state == EOS_STATE || eos)
            {
                log.error("getBufferLeftCalled MediaPlayer in EOS_STATE");
                return -1;
            }

            //Buffers are empty, and Server has already informed us of EOS.
            // I think this assumes that buffer would never be 0 if there was data left for us to read.
            if(((HasPushBuffer) dataSource).getEOS() && ((HasPushBuffer) dataSource).dataAvailable() == 0)
            {
                log.error("getBufferLeftCalled MediaPlayer bufferAvailable is 0, setting EOS and returning EOS");
                state = EOS_STATE;
                return -1;
            }

            log.error("getBufferLeftCalled bufferAvailable: " + ((HasPushBuffer) dataSource).bufferAvailable());

            return ((HasPushBuffer) dataSource).bufferAvailable();
        }
        else
        {
            return PushBufferDataSource.PIPE_SIZE;
        }
    }

Now I want to set the fast_mux_swtich back on and see if I can figure that out. Maybe fast_mux_switch path should not be executed when the transcoder is in use? I am not sure. Let me know if you think I might be on the right track.

[wnjj]

My first instinct is to agree that fast mux switch should be off when transcoding. Now it may be possible to support it if the transcoder can seamlessly stop transcoding one file, and the start the next without interrupting the stream of frames but that may take a bunch of work.

I know that the seeker code calls into an encoder function called “supportsFastMuxSwitch” to discover if the particular encoder in use supports it. Finding a way to block/alter that response seems like the cleanest way to override it if transcoding does not support it.

You may try PM’ing Narflex as to his thoughts on this.

[nyplayer]

Originally Posted by wnjj

I’m not sure but I think fast mux switching is only for live TV. Without fast mux mode, there’s a slight delay/freeze when the show changes to the next one.

I fixed it by deleting and recreating new Playlist guess somehow some of them got corrupted.

[jvl711]

Originally Posted by wnjj

My first instinct is to agree that fast mux switch should be off when transcoding. Now it may be possible to support it if the transcoder can seamlessly stop transcoding one file, and the start the next without interrupting the stream of frames but that may take a bunch of work.

I know that the seeker code calls into an encoder function called “supportsFastMuxSwitch” to discover if the particular encoder in use supports it. Finding a way to block/alter that response seems like the cleanest way to override it if transcoding does not support it.

You may try PM’ing Narflex as to his thoughts on this.

So I added some code into seeker to check to see if there is a client that is currently transcoding the current media file and the capture device is being controlled by a client. If those are both true than I am cancelling fastMuxSwitch. This seems to be working really well so far. I need to do a lot more testing, but I am happy to report, that for the first time in a long time the placeshifter was able to switch from one airing to another without freezing!

So I have two changes currently for the Android Client and SageTV Core to make timeshift work properly while transcoding.

I also PMed Narflex to see if he had another path suggestion.

Josh

[nyplayer]

Is there a setting (properties) on the SageTV server to always turn on Subtitles ?

[gexi]

Originally Posted by jvl711

Older versions are available in GitHub to sideload.

FYI, avi files were not supported in ExoPlayer. I changed the config to tell SageTV that ExoPlayer does not support AVI so that it could be transcoded. If you are using Dynamic streaming mode your millage may vary.

Josh

First let me say I think you've been doing awesome with the updates but I did end up having to rollback this time to 1.7.0 on my FireTV devices.

I tried completely rebuilding my SageTV install with 9.2.2 from the ground up, installed the updated SageTVTranscoder FFmpeg plugin, the Media Format Parser Plugin, as well as the new sage.jar that goes with them. I tried switching all the settings in exoplayer and ijk but nothing would let it play files that were working with the previous release.

Jumping back to the sideloaded 1.7.0 version and switching to ijk resolved all the issues and all media files are playable again. It appears that something in the 1.7.1 version has broken some file formats as well as in file seek in ijk on Amazon FireTV and FireTV Stick.