Anyway to block Roku App upgrades?

[JXL2112 7]

I don't upgrade Emby Server very often, I like tried and true but the Roku App upgrades when I connect to the web. This always causes problems.

 

I had Emby Server 4.2 and Roku App 3.0.175 working great. Then 193 came out and it's driving me crazy. I don't know how to downgrade back to 175 since I don't know the Roku platform that well.

 

Can I block upgrades or side load the older 175?

 

If not maybe you can allow us to stay on older versions longer until all the bugs are actually worked out....your destroying your own product and reputation.

[Luke 37063]

Hi there, we're happy to help you with your issue. What problem are you having?

[Happy2Play 8281]

No you can not side load the Emby Roku channel as it is not open source.  So the code currently will not be released.

[ebr 14912]

Hi.  Please detail the issue you are having and I'm pretty sure we can help.  We are not aware of any major bugs in the latest release.

 

I don't believe there is any way to keep Roku apps from updating.

[JXL2112 7]

Hi.  Please detail the issue you are having and I'm pretty sure we can help.  We are not aware of any major bugs in the latest release.

 

I don't believe there is any way to keep Roku apps from updating.

 

I load an album to play and it won't play the entire queue, it stops with a few seconds left in almost every song.

 

I tried 193 and beta 197 and they both have this bug.

[ebr 14912]

Hi.  Can you please provide more specifics?

 

How to Report a Problem

[Gilgamesh_48 943]

FWIW: The Roku automatic updates have been a sore point for many users for a very long time. Obviously completely disconnecting from te internet will prevent updates but that proves to have many bad side effects and prevents all updates and prevents all Roku apps from working if they require or use the internet to function.

 

Many people have shown ways to block various update servers and that works for a while but at some point you miss an update that is required to keep an app functioning because the provider makes a backend change of some kind.

 

It is best to allow all updates and deal with the changes as they come rather that trying to micro-manage the update system.

 

Almost all decent companies test their release versions very well and, when there are issues, work well with the user base to fix what is wrong ASAP. Emby is a company that pretty much defines decency.

 

Work with the Emby developers and almost all the time any issue will be resolved in a reasonable amount of time. Of course you will need to help the developers help you by providing all the information that is requested.

[speechles 1917]

I load an album to play and it won't play the entire queue, it stops with a few seconds left in almost every song.

 

I tried 193 and beta 197 and they both have this bug.

 

What are the media details for those problem items? Are these mp3? Are they m4a with AAC inside? Maybe ALAC in m4a? 

 

We are doing changes to the audio player to improve it. Part of these changes include better handling of issues just like this. This is why I am curious what the media information is for those items.

 

Are any ffmpeg logs created during these playing? Can you share those with us? 

 

I do not experience this at all and I am testing new music changes as we speak, literally, right now. I have diligently tried to fix every single playback issue and no longer myself can I reproduce these problems. Even my intentionally broken and corrupt files will error and be skipped/ignored correctly. The fallback transcoding works perfectly. This is why I am sure what we have in the pipeline is going to cure these problems. But cannot be sure until you tell us they have.

 

Please get back to us with any ffmpeg logs and the media information for those files. Thank you very much. We can surely solve this if it isn't something we have already addressed. Can we fix it? Yes we can.

Edited November 26, 2019 by speechles

[speechles 1917]

FWIW: The Roku automatic updates have been a sore point for many users for a very long time. Obviously completely disconnecting from te internet will prevent updates but that proves to have many bad side effects and prevents all updates and prevents all Roku apps from working if they require or use the internet to function.

 

Many people have shown ways to block various update servers and that works for a while but at some point you miss an update that is required to keep an app functioning because the provider makes a backend change of some kind.

 

It is best to allow all updates and deal with the changes as they come rather that trying to micro-manage the update system.

 

Almost all decent companies test their release versions very well and, when there are issues, work well with the user base to fix what is wrong ASAP. Emby is a company that pretty much defines decency.

 

Work with the Emby developers and almost all the time any issue will be resolved in a reasonable amount of time. Of course you will need to help the developers help you by providing all the information that is requested.

 

The problem you face is momentum. We cannot just be happy with the status quo. The way things are. We must always improve. People expect time to mean more features, more bug fixes, more advancements. Part of that is the fact that legacy methods and ways things were done have to be abandoned eventually. Because the code to support those old methods may be too hard to maintain. Having to maintain two routes(or more) to the same data depending on server version the user has. We do this often in the Roku app but we must at some point consider a server version too old too be used with the application. We just have to for sanity.

 

To keep working in fixes to support older versions of the server would take away from serious development time. Those who do update to new versions of the server would in effect be punished. Those users are doing nothing really wrong. Nor are users who do not update. But if you have to choose whose installation will break first. You will choose those who didn't update. This is just natural.

 

We cannot "freeze time" and expect this to become reality. The Roku ecosystem updates. The Emby ecosystem updates. They are just a necessary part of our digital lives these updates.

 

We cannot be "Okay, Boomer!" about this. But at the same time we cannot keep supporting older server versions just because we can. It is next to impossible to do that as you are inside a maze. The code can become spaghetti pretty quickly. To prevent this we must all update. Even us boomers. I am more gen-x than boomer. Closer to gen-x anyways. I turn 50 on Dec 1st this year, yes, seriously. Time stands still for no man.

Edited November 26, 2019 by speechles

[Gilgamesh_48 943]

...

We cannot be "Okay, Boomer!" about this. But at the same time we cannot keep supporting older server versions just because we can. It is next to impossible to do that as you are inside a maze. The code can become spaghetti pretty quickly. To prevent this we must all update. Even us boomers. I am more gen-x than boomer. Closer to gen-x anyways. I turn 50 on Dec 1st this year, yes, seriously. Time stands still for no man.

 

Of course you, and all Roku app developers must continuously move forward. Apps that do not move forward at a reasonable pace eventually die. There are numerous examples in the Roku channel store that died some time ago and there are even more that are running in a way that is nearly worse than death. Roku, at least for the foreseeable future, moves their platform forward and all apps must move to adapt to that. Along with that the apps that are in two parts (client server types) must evolve to support changes made to the server side.

 

Emby actually seems to handle changes better than most and is MUCH more responsive to changes than most of their competitors. (Plex??) Emby is also VERY fast to fix any bugs that get missed in beta testing.

 

BTW: You are still just a child. Anyone that was not alive during the Eisenhower administration has not aged sufficiently to be thoroughly dry behind the ears.

 

But I leave you with a thought that was impressed on a coffee mug my ex-wife gave to me on my 50th birthday: "You have just turned 50, you will never have fun again for the rest of your life." The mug, and wife, were quite wrong.

[JXL2112 7]

What are the media details for those problem items? Are these mp3? Are they m4a with AAC inside? Maybe ALAC in m4a? 

 

We are doing changes to the audio player to improve it. Part of these changes include better handling of issues just like this. This is why I am curious what the media information is for those items.

 

Are any ffmpeg logs created during these playing? Can you share those with us? 

 

I do not experience this at all and I am testing new music changes as we speak, literally, right now. I have diligently tried to fix every single playback issue and no longer myself can I reproduce these problems. Even my intentionally broken and corrupt files will error and be skipped/ignored correctly. The fallback transcoding works perfectly. This is why I am sure what we have in the pipeline is going to cure these problems. But cannot be sure until you tell us they have.

 

Please get back to us with any ffmpeg logs and the media information for those files. Thank you very much. We can surely solve this if it isn't something we have already addressed. Can we fix it? Yes we can.

 

 

They are 16-bit Flac files ripped from CD's....the files play fine but the queue won't advance....it just stops with 2 or 3 seconds left. I have to use the Roku remote to advance to the next song.

 

This isn't the first time a Roku App upgrade broke the auto-queue...

 

I'll find the ffmpeg logs file and upload.

[speechles 1917]

They are 16-bit Flac files ripped from CD's....the files play fine but the queue won't advance....it just stops with 2 or 3 seconds left. I have to use the Roku remote to advance to the next song.

 

This isn't the first time a Roku App upgrade broke the auto-queue...

 

I'll find the ffmpeg logs file and upload.

 

Yeah.. this is definitely ffmpeg "no likey" flac->aac conversion perhaps. Because that is what might be happening. If so we can tailor flac to use mp3 when fallback transcoding. That is the likely scenario playing out here. Your ffmpeg log will confirm or deny that. Thanks.

Edited November 27, 2019 by speechles

[ebr 14912]

Hi.  Can you please test the latest beta version of the Roku app on these music files?

 

Thanks.

[JXL2112 7]

Hi.  Can you please test the latest beta version of the Roku app on these music files?

 

Thanks.

 

Tested and it works. However since these are Flac files why not transcode them to wav format?

 

MP3 is a format I stay away from....really degrades the sound quality.