Theme: blue neon night

[Waldonnis 148]

Finally found some time to track down a crash that's been bugging me lately 

 

When the "Enhanced Descriptions" option is set to no, entering the special features screen for a movie will crash back to the main Roku screen.  It's claiming a type mismatch on line 453 of VideoMetadata.brs, but it looks like MetaData.shortdescriptionline2 is actually null when that option is set to "no", and no test is being performed to make sure it's not invalid before the assignment.  Enclosing the line inside a conditional (invalid check) allowed it to work fine again, so it's a simple fix.

 

For reference, the exact line is:

MetaData.shortdescriptionline2 = trLoc + metaData.shortdescriptionline2

When enhanced descriptions is set to "yes", shortdescriptionline2 contains expected values given that setting (runtime and play count) and no crash happens, as expected.

 

Not a big showstopper and I'm frankly surprised I never ran across this before.  I guess I was messing with the settings during a debugging session in the past and just left that off without noticing (and without playing any special features since then, apparently).

[dubhju 0]

My mixed content libraries have gone wonky on the home screen - any thoughts on why & how to fix?  It seems to look right in the official emby app (but... I don't like that one! )

 

Directory structure like this

 

Root Folder (of media library)

  - TV

    - ShowA

    - ShowB

    - ShowC

  - Movies

  - Stuff

  - More Stuff

 

It used to show more like folder view.  homescreen for that libarary row showed TV, Movies, Stuff, More Stuff.  When entering TV, it would have ShowA, ShowB, ShowC.  Entering a show it would have the seasons display

 

It still has those folders, but mixed in with it are 1000 loose episodes from subfolders. The first item is one of the shows season 1 episode 1, etc

 

I tried creating a new library with 2 shows, and the main screen shows "Show A season 1", "Show B season 1", "Show A season 2", "Show B season 2"

[speechles 1929]

New Version: v3.85
* fix "device info" so it doesn't crash rokuTV
* fix detect rokuTV automatically
* remove "direct play mpeg1/2" preference
* fix brightscript crash

The new "device info" button was crashing rokuTV. isHDMIconnected was causing this. Removed that since roku has deprecated it in firmware 7.x. This should now allow rokuTV to use device info. *Crosses fingers*

Added a new setting isRokuTV to capabilities so mpeg1 and mpeg2 streams will direct play automatically if a rokuTV is detected. This makes the "direct play mpeg1/2" preference obsolete so it has been removed.

Also fixed the brightscript crash @@Waldonnis mentions above. ^_~

Updated all links in first post. Enjoy, and rokuTV does this fix "device info" button?

[BAS 225]

I've seen the default to 12 items cause I use items/latest. I just switch category on home screen and all is well as workaround but probably will just tell my users to leave alone and deal with the flood of content of one show that appears in latest tv occasionally when i put in a whole season at once.

 

When entering prefs for detailed statistics to change yes or no, the page reads enhanced descriptions.

 

I see the hide watch from suggested is in prefs, and its default is on, but I'm still getting watched suggestions for items.

 

Cinema Mode - My server is set to only play 2 trailers from my local library, no internet trailer plugin, these 2 trailers come from unwatched movies in my library only. Works fine elsewhere, on Roku it plays the trailer of unwatched movie I'm about to watch then another trailer, then the movie. So for example, I went to watch aliens, it played the aliens trailer first thing. Update web client appears to be doing the same thing now as well.

 

Cinema Mode - Ran into a corrupt trailer which caused a playback error, instead of playing the next trailer, or the movie it just flat out stops. Work around was to play movie from scene chapter 1. Tested the trailer that caused this playback error on web client and it works fine. Hmmm seems odd will have to investigate the file format/codecs.

Edited October 21, 2016 by BAS

[speechles 1929]

I've seen the default to 12 items cause I use items/latest. I just switch category on home screen and all is well as workaround but probably will just tell my users to leave alone and deal with the flood of content of one show that appears in latest tv occasionally when i put in a whole season at once.

 

When entering prefs for detailed statistics to change yes or no, the page reads enhanced descriptions.

 

I see the hide watch from suggested is in prefs, and its default is on, but I'm still getting watched suggestions for items.

 

Cinema Mode - My server is set to only play 2 trailers from my local library, no internet trailer plugin, these 2 trailers come from unwatched movies in my library only. Works fine elsewhere, on Roku it plays the trailer of unwatched movie I'm about to watch then another trailer, then the movie. So for example, I went to watch aliens, it played the aliens trailer first thing.

 

Cinema Mode - Ran into a corrupt trailer which caused a playback error, instead of playing the next trailer, or the movie it just flat out stops. Work around was to play movie from scene chapter 1. Tested the trailer that caused this playback error on web client and it works fine. Hmmm.

The "detailed statistics" text issue. HAW.. That one has been there since that was added. Nice find. I've corrected that text now to show correctly.

 

The Suggested isn't respecting the "filters=isUnplayed" when polling for suggested movies. This is the servers fault. I am correctly passing the filter to the endpoint it just isnt following it.

 

The cinema mode issue, yes indeed. When something doesn't play correctly it will kill your entire play queue. So if you set "force directstream" and the movie can play this way.. but.. trailers before it must be transcoded this would cause the problem. The trailer would cause the entire play queue to stop. This is now corrected too.

 

The videoplayer will now show a dialog it is skipping the unplayable item, and move to the next one. This uses the isPlaybackError boolean correctly now. So if you exit a video before it buffers completely using the back button it no longer shows as a playback error. If there is an error and it is within a playqueue it reports the error via dialog, waits 1.5 seconds so you can see the dialog, then closes that dialog, resets the isPlaybackError to false, and moves to the next item in the play queue and restarts the videoplayer. In testing so far this seems to alleviate the problem completely. It also makes the app look smarter.

 

You are an awesome tester BAS. Thanks, and expect these changes to make it into the next version. Hopefully if all testing goes well there will be a new version later today.

Edited October 21, 2016 by speechles

[BAS 225]

I updated my last post a little. Thanks for the fixes as always. Will look forward to the suggested when the server respects your request. Now to see if anyone else is using cinema mode like me and has reproduced this annoying bug.

 

Doesnt look like it.

 

https://emby.media/community/index.php?/topic/40541-cinema-mode-playing-trailer-for-the-movie-im-about-to-watch/&do=findComment&comment=378710

Edited October 21, 2016 by BAS

[speechles 1929]

@@BAS

 

Also had time to investigate the fallback to transcoding if direct play fails. This works now like plex. If the item cannot direct play it will automatically fall back to transcode. If there is an error as it transcodes, the second error will cause the videoplayer to abort.

 

Here is how it will work. Once the videoplayer gets an error it causes the player to close. This in turn causes the app to check how many items are in the play queue. If there is just one item, then it will attempt to fallback to transcoding for this single item. This should work around the 4GB bug just like plex handles it.

 

If there are multiple items, it will skip the items errored on, show a dialog they are unplayable and move to the next. This allows you to use "force directstream" and any items needing transcoding get skipped. If you use cinema mode, this can skip problem trailers and go right to the movie. Once on the movie, it is now a single item. This can then fallback to transcoding.

 

Still tweaking things slightly, but this will also make the next release due today. Just keeping you aware whats going on next.

 

Sent from my Nexus 7 using Tapatalk

Edited October 21, 2016 by speechles

[speechles 1929]

New Version: v3.86

* fix detailed statistics preference text (thx BAS)

* add fallback mechanism to videoplayer

* add fallback setting to preferences

* add video skip when multiple items are played

 

Thanks to BAS for the preference fix.

 

The fallback mechanism is now complete. This will help work-around the 4GB issue automatically. It will fallback to transcoding when applicable. This also has a setting in preferences. This will control how many retries are attempted before giving the video player prematurely exited error. This also adds the ability for the video player to reject items it cant play if it is given a video queue. You may see a dialog telling you a video is unplayable and it skips to the next when using continuous play.

 

Enjoy, and let me know if there are any problem spots. Updated all links in first post.

 

Anyone want to test this? Choose "force directstream" and let me know if it automatically switches to transcoding at the 4GB spots.

Edited October 22, 2016 by speechles

[mikeraburn 60]

Confirmed

EAC3 direct plays on the Roku Plus, even on my goofy system.

(not that I didn't trust what speechles said)

 

I used that 1/2 off offer on the plus because I had the 4.

[speechles 1929]

Confirmed

EAC3 direct plays on the Roku Plus, even on my goofy system.

(not that I didn't trust what speechles said)

 

I used that 1/2 off offer on the plus because I had the 4.

Nice...I went through the capabilties today, and cleaned up alot of issues. The device capabilties no longer rely on model numbers. This means all of the devices capabilties are immediately supported if detected. There is no guessing, or waiting until your model is known in order to be supported anymore.

 

There is full 4k support if hevc or vp9 decoding capability is present on the device (roku suggested this). There is also full audio codec and channel detection (roku suggested this too). Ive also added eac3 as a copyable codec if DD+ is found (copy > transcode). This should bring full support to all devices, and all models of rokuTV.

 

I will have a new release tomorrow for everybody to try out. Until then... stay tuned...

[mikeraburn 60]

I think I did have to FORCE Direct Play for EAC3, auto detect didn't catch it.

(you may have stated that above)

 

ALSO, private listening is no longer transcoded.

(you may have addressed that earlier too)

I tested that using the app on my phone.

[speechles 1929]

I think I did have to FORCE Direct Play for EAC3, auto detect didn't catch it.

(you may have stated that above)

 

ALSO, private listening is no longer transcoded.

(you may have addressed that earlier too)

I tested that using the app on my phone.

It will catch the DD+(eac3) on auto in the next version. It is using the exact methods roku has suggested apps use. So this will be as accurate as it can get. There will be a new MaxRefFrame preference in the next app. The firmware on new models (4610, 4620, 4630, and 4640) presently has issues with refframes over 12. The auto-detection defaults to 15. The next version of the app will set this default as 12. You can choose 5, 8, 12, 15, or 16 for it in the preference. This part cant be auto-detected.

 

The private listening requires you choose "auto-detection private" to enable it. This mode will force all audio streams to stereo and sends the server different capabilities. There is no way to auto-detect you are using private listening. So this is the work-around. If you use a surround sound codec it will produce no sound in private listening unless you are using auto-detection private.

Edited October 23, 2016 by speechles

[Waldonnis 148]

* add auto direct play eac3 up to 7.1 to premier+ (4630) and ultra (4640)

 

New roku models add new audio capabilities. The premier and ultra can support eac3(DD+) up to 8(7.1) channels. Added preliminary support for these models to auto direct play. Also added auto direct play for hevc/vp9 for these models. You couldve already "force directstream" these and direct played. This adds the ability to "auto-detection" to support it.

 

Oddly, my Roku 3 (4200) that's connected to an A/V receiver reports that the audio sink can support eac3 7.1 (via passthrough, obviously), so older models may support it as well.  This is on the current production firmware (7.2.0, build 4100), btw.  I haven't made a test case for it, though, so I'm not sure if it actually works or not.

 

GetAudioDecodeInfo() results:

<Component: roAssociativeArray> =
{
    AAC: 2:0:0:0:
    AC3: 6:0:0:1:
    ALAC: 6:0:0:0:
    DD+: 8:0:0:1:
    DTS: 7:0:0:1:
    FLAC: 6:0:0:0:
    LPCM: 6:0:0:0:
    MP3: 2:0:0:0:
    MPEG2: 2:0:0:0:
    WMA: 6:0:0:0:
    WMAPRO: 8:0:0:0:
}

CanDecodeAudio() results:

di.CanDecodeAudio({Codec: "eac3", ChCnt: 8})
<Component: roAssociativeArray> =
{
    result: true
}

Edited October 23, 2016 by Waldonnis

[speechles 1929]

@@Waldonnis

 

Detect 4k (in capabilities.brs):

    if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
        supports4k = (device.CanDecodeVideo({codec: "hevc"}).result = true or device.CanDecodeVideo({codec: "vp9"}).result = true)
    else
        supports4k = false
    end if

 

Detect Audio Codec Support (in appmain.brs):

        audioDecoders = device.GetAudioDecodeInfo()

 

       ' Check for surround sound codecs:

        hasDolbyDigital = audioDecoders.doesexist("AC3")
        hasDolbyDTS = audioDecoders.doesexist("DTS")
        hasDDPlus = audioDecoders.doesexist("DD+")

        ....

        GetGlobalAA().AddReplace("audioOutput51", hasDolbyDigital)
        GetGlobalAA().AddReplace("audioDTS", hasDolbyDTS)
        GetGlobalAA().AddReplace("audioDDPlus", hasDDPlus)

 

Detect Audio Channel Support (in capabilities.brs):

    device = CreateObject("roDeviceInfo")

    audio = device.GetAudioDecodeInfo()

    ....

    AACchannels = left(audio.lookup("AAC"),1)

   AC3channels = left(audio.lookup("AC3"),1)

  EAC3channels = left(audio.lookup("DD+"),1)

  dcaChannels = left(audio.lookup("DTS"),1)

 

The FLAC, WMA, LPCM, and ALAC do not have restrictions on number of channels so are working depending on the devices firmware version usually anything over 5.3 has them, under doesn't. Why fix what isn't broken so this part I didn't change to read from the GetAudioDecodeInfo().

 

 

The CanDecodeAudio() is damn near useless since it doesn't support bitrate or container... yet?! Must be since its so under-developed and half-baked. Roku mentions not even trusting CanDecodeVideo() yet, except in cases you need to tell a 4k display by asking it about hevc or vp9 like I do above. This means it is still better to keep the existing system in place for capabilities since it has far more accurate detection with the way profiles are used. This is why I don't make use of either of those CanDecode_____ methods yet. Especially since the aim is support all roku/nowTV devices. We know better than roku does ATM what plays and what doesn't. ^_~

Edited October 23, 2016 by speechles

[Waldonnis 148]

Okay, I just wanted to be sure that it wasn't exclusive to specific models (like the older code was).  I'm actually preparing a test case for eac3 since I'm just genuinely curious at this point and have some TrueHD streams to test with

 

Edit: Or not.  I apparently don't have an audio encoder that supports 8-channel eac3 (despite having about five of them  ).  *keeps digging through my a/v toolbox*

 

The only other thing that I wouldn't mind having someone test (if possible) is if 4k h.264 files work properly on the 4k-supporting models.  I think there were some hard-coded resolution caps before, but haven't looked to see if that code has been modified since or if it would've been restrictive of such a case (that's what I was working on before I got busy with other stuff, so I didn't do more than a few cursory passes on it).  I know some folks still use h.264 for some 4k content for various reasons and, while rare, it's something to check out.  I'm also not sure if the level restrictions in the firmware would even support 4k h.264 (or, really, if the hardware decoder can handle it).

 

I may have some time soon and will try to catch up a bit to hopefully be more contributory again.

Edited October 23, 2016 by Waldonnis

[speechles 1929]

Okay, I just wanted to be sure that it wasn't exclusive to specific models (like the older code was).  I'm actually preparing a test case for eac3 since I'm just genuinely curious at this point and have some TrueHD streams to test with

 

Edit: Or not.  I apparently don't have an audio encoder that supports 8-channel eac3 (despite having about five of them  ).  *keeps digging through my a/v toolbox*

 

The only other thing that I wouldn't mind having someone test (if possible) is if 4k h.264 files work properly on the 4k-supporting models.  I think there were some hard-coded resolution caps before, but haven't looked to see if that code has been modified since or if it would've been restrictive of such a case (that's what I was working on before I got busy with other stuff, so I didn't do more than a few cursory passes on it).  I know some folks still use h.264 for some 4k content for various reasons and, while rare, it's something to check out.  I'm also not sure if the level restrictions in the firmware would even support 4k h.264 (or, really, if the hardware decoder can handle it).

 

I may have some time soon and will try to catch up a bit to hopefully be more contributory again.

 

The TrueHD test in the blue neon app? If you enable that it actually turns on both True-HD and DTS-HD MA in 7.1 channels. So you can test either or, find out yeah doesn't work... then disable. I do that everytime there is a firmware update. The blue neon app also has the h264 in 4k preference. I read an ljunkie(plex) post and saw no roku model supports h264@4k. But really the best way to know 100% is trying it yourself. This is why those options are in the app.. heh.. They are like science experiments you can try yourself at home. Thats also why it has robust device info that would be useful as an app on its own. These touches help me test theories so much faster having them out in the wild for anyone to try.

 

The next app I added a preference for DD+ pass-through, has either "auto" or "off" for choices. This will help if your device detects DD+, but somehow it won't play back correctly. You can disable it entirely with a switch. These extra options come in handy. 

Edited October 23, 2016 by speechles

[Waldonnis 148]

The TrueHD test in the blue neon app? If you enable that it actually turns on both True-HD and DTS-HD MA in 7.1 channels. So you can test either or, find out yeah doesn't work... then disable. I do that everytime there is a firmware update. The blue neon app also has the h264 in 4k preference. I read an ljunkie(plex) post and saw no roku model supports h264@4k. But really the best way to know 100% is trying it yourself. This is why those options are in the app.. heh.. They are like science experiments you can try yourself at home. Thats also why it has robust device info that would be useful as an app on its own. These touches help me test theories so much faster having them out in the wild for anyone to try.

 

The next app I added a preference for DD+ pass-through, has either "auto" or "off" for choices. This will help if your device detects DD+, but somehow it won't play back correctly. You can disable it entirely with a switch. These extra options come in handy. 

 

TrueHD isn't E-AC-3/DD+, so this is a separate test.  Both support 8 channels, but there are quite a few differences (channel mixing, bitrate limits...not to mention that TrueHD is lossless while eac3 isn't).  It's really not used in NA much (if at all now), but I've seen a few foreign discs on the market with eac3 tracks.  It's a quirky case, so maybe I'll try to find a sample since I can't seem to make my own with the myriad of audio encoders I have here.

 

As for 4k h.264, that's kinda what I figured.  I can't test because I lack a 4k-supporting Roku, but it wouldn't surprise me if the h.264 decoder in the SoC just doesn't have the silicon/muscle for it (not worth the cost for Roku to source one that does, since HEVC is more accepted for 4k anyway, so it's understandable).  It was more of a curiosity point for me anyway, and really not worth worrying about.

[speechles 1929]

TrueHD isn't E-AC-3/DD+, so this is a separate test.  Both support 8 channels, but there are quite a few differences (channel mixing, bitrate limits...not to mention that TrueHD is lossless while eac3 isn't).  It's really not used in NA much (if at all now), but I've seen a few foreign discs on the market with eac3 tracks.  It's a quirky case, so maybe I'll try to find a sample since I can't seem to make my own with the myriad of audio encoders I have here.

 

As for 4k h.264, that's kinda what I figured.  I can't test because I lack a 4k-supporting Roku, but it wouldn't surprise me if the h.264 decoder in the SoC just doesn't have the silicon/muscle for it (not worth the cost for Roku to source one that does, since HEVC is more accepted for 4k anyway, so it's understandable).  It was more of a curiosity point for me anyway, and really not worth worrying about.

 

Yeah, the trueHD test in the blue neon app allows pass-through of the audio. I get no audio though as my equipment doesn't support trueHD, So might be passing through silence at the same time.

 

http://kodi.wiki/view/Samples

http://www.divx.com/en/devices/profiles/video

 

These are most of the samples I use in one spot. If you can play all these you are good.

[Waldonnis 148]

Yeah, the trueHD test in the blue neon app allows pass-through of the audio. I get no audio though as my equipment doesn't support trueHD, So might be passing through silence at the same time.

 

http://kodi.wiki/view/Samples

http://www.divx.com/en/devices/profiles/video

 

These are most of the samples I use in one spot. If you can play all these you are good.

 

The older Roku 3 definitely doesn't pass TrueHD or DTS-HD through...I've tried.  I doubt any of the models prior to this latest generation do either since firmware seems to be what prevents it.  DTS-HD passes the lossy 5.1 core through, but TrueHD won't work (as TrueHD may not have a core since it's not required).

 

I've seen user reports that the new models don't either, but can't confirm it either way and I generally don't trust user reports (the channels they're using to test may be the limiting factor).  Strangely enough, DTS-HD is listed as an example value in their CanDecodeAudio() documentation blurb, but I have yet to see it actually in the codec array list returned from that function, even though my receiver supports everything (except Atmos).  Hoping the support for it is something they just haven't gotten around to adding yet.

 

Thanks for the links - I'll poke through the samples.  I didn't see one in the Kodi samples when I looked earlier, but there may be one in the DIVX samples (I think I saw one attached to an ffmpeg bug report somewhere too).

[speechles 1929]

The older Roku 3 definitely doesn't pass TrueHD or DTS-HD through...I've tried.  I doubt any of the models prior to this latest generation do either since firmware seems to be what prevents it.  DTS-HD passes the lossy 5.1 core through, but TrueHD won't work (as TrueHD may not have a core since it's not required).

 

I've seen user reports that the new models don't either, but can't confirm it either way and I generally don't trust user reports (the channels they're using to test may be the limiting factor).  Strangely enough, DTS-HD is listed as an example value in their CanDecodeAudio() documentation blurb, but I have yet to see it actually in the codec array list returned from that function, even though my receiver supports everything (except Atmos).  Hoping the support for it is something they just haven't gotten around to adding yet.

 

Thanks for the links - I'll poke through the samples.  I didn't see one in the Kodi samples when I looked earlier, but there may be one in the DIVX samples (I think I saw one attached to an ffmpeg bug report somewhere too).

 

There's also these sites, within the kodi link:

http://kodi.wiki/view/Samples#Resources_for_Additional_Test_Clips_or_Samples

 

Yeah, the examples they use for CanDecodeAudio make use of bitrate and container too.. so go figure. Those aren't even supported yet and always give "na" as a reply. So rokuCo is def smoking crack when it comes to sdk documentation and written examples in that documentation. Its almost (almost..haw..enitrely, more like it) possible they dont understand everything either. It would be easier if all the stuff worked as it does in their examples. But somehow their examples are using some firmware version no one else in the world has since the examples seem to work for them. Strange stuff going on in that roku development lab. NDA happy too. Don't discuss fight club! I've seen them chastise people in threads for even mentions that firmware 7.6 is in the wild. ;D

[Waldonnis 148]

There's also these sites, within the kodi link:

http://kodi.wiki/view/Samples#Resources_for_Additional_Test_Clips_or_Samples

 

Yeah, the examples they use for CanDecodeAudio make use of bitrate and container too.. so go figure. Those aren't even supported yet and always give "na" as a reply. So rokuCo is def smoking crack when it comes to sdk documentation and written examples in that documentation. Its almost (almost..haw..enitrely, more like it) possible they dont understand everything either. It would be easier if all the stuff worked as it does in their examples. But somehow their examples are using some firmware version no one else in the world has since the examples seem to work for them. Strange stuff going on in that roku development lab. NDA happy too. Don't discuss fight club! I've seen them chastise people in threads for even mentions that firmware 7.6 is in the wild. ;D

 

No kidding.  I'm guessing the docs are the result of a disconnect between their tech writers and the development team (same was the case in two places I worked, which was frustrating for everyone).  The tech writers get the design specs and some rudimentary examples, but never get notified of what actually gets implemented, so it ends up being an inconsistent mess.  For basic codec checks, the CanDecodeXXX() functions work quite well, but if you add any of the other potential arguments, you never know if you're getting the correct answer (too often, it's not).  At least ChCnt works well for audio codec checks...at least in the cases I've tried so far.

 

Don't even get me started on the NDA requirements.  I'm a stickler for adhering to any NDAs I accept, but many of them go way too far in what they restrict for my taste.  I stick to them when I choose to accept them (video game alpha NDAs mostly these days, which are more interested in a media-blackout of a pre-released product than in protecting trade secrets), but I generally won't do anything that would require one these days because they often are beyond what I consider reasonable.  Meh, off topic, but I agree that their NDA is a bit on the wacky side (which is why I won't accept it).

[speechles 1929]

New Version: v3.87
* add MaxRefFrame Preference
* add DD+ preference
* fix DTS detection fully
* add full support for all audio codecs
* fix capabilities to work on any device

There is two new preferences:
Maximum RefFrames helps new roku devices, default is 12. Set this to 16 until if you want. The old default was 15. Everyone should set this up to 16 and see if they have issues. By default, it will stay in the "safe zone" and stay at 12.

DD+ Pass-Through helps if your system detects DD+ but you get no audio. You can now easily fix this by turning DD+ off.

The DTS detection was faulty before. It was causing DTS to fail(require transcoding) on never firmware. This is now corrected. Also went through the entire capabilities and added full support for every audio codec and limited them by the devices audio channel support. This means you should _always_ get sound with auto-detection. Depending on how the device reports its audio decode information directly affects how the app will work on that device. This also adds full support for rokuTV, for new roku models, for any roku device. There is no guessing anymore.

Because of how the emby platform works with profiles, the device has to let emby know every audio&video codec and container it can play. It is similar to building a DLNA profile. These profiles are comprehensive. You can't really use the "CanDecodeXXX" functions to build a capabilities profile because these functions aren't robust enough to detect framerate, refframes, bitrate, etc. It would be far less accurate than the model used now.

Has anyone tried out the new transcoding fallback when direct playing? Someone who had problems before with the 4GB firmware bug? You don't need to "force transcode" as the app will self-recover the stream and restart the video player with transcoding. Try using "force directstream" on an item you know has to transcode. It will show the fallback in action too. Sorry it took so long to get this added. For those that don't want fallback, use the preference "fallback retries" and set this to 0. It will work like it did before with no fallback.

Updated all links in first post. Enjoy, and if you spot a problem, please don't hesitate to mention it. There were major changes to the capabilities, so please test this with multiple video/audio codecs. It should be fool-proof now and always do the right thing.

Edited October 23, 2016 by speechles

[Waldonnis 148]

The DTS detection was faulty before. It was causing DTS to fail(require transcoding) on never firmware. This is now corrected. Also went through the entire capabilities and added full support for every audio codec and limited them by the devices audio channel support. This means you should _always_ get sound with auto-detection. Depending on how the device reports its audio decode information directly affects how the app will work on that device. This also adds full support for rokuTV, for new roku models, for any roku device. There is no guessing anymore.

I'll test this tomorrow, if needed (commandeering the living room television on Sunday nights is a capital crime around here  ).

 

Has anyone tried out the new transcoding fallback when direct playing? Someone who had problems before with the 4GB firmware bug? You don't need to "force transcode" as the app will self-recover the stream and restart the video player with transcoding. Try using "force directstream" on an item you know has to transcode. It will show the fallback in action too. Sorry it took so long to get this added. For those that don't want fallback, use the preference "fallback retries" and set this to 0. It will work like it did before with no fallback.

I did a quick test earlier and it did fall back to transcoding, but it started on the chapter marker rather than the rough time of the player crash (~60secs beyond the chapter start point, in this case), leading to a replaying of the chapter from the beginning.  I only ran one test and started playback at that chapter, so it could've been an oddball occurrence.  I'll try playback from the beginning and let it run (crash point is only 22mins in) to see if it does the same, then post an update.

 

Update: It seems to start transcoding from the point of initial playback.  I started the movie from the beginning and, when it hit the crash point, it started the movie over again (this time, transcoding).

 

Oh, update about eac3: ffprobe doesn't detect 8-channel eac3 properly (returns that it has 6 channels), so Emby doesn't recognise it properly anyway.  At least I found an eac3 8-channel audio sample file, so I just generated a blank screen video stream to go with it and will run that test tomorrow as well.

Edited October 24, 2016 by Waldonnis

[mikeraburn 60]

"The DTS detection was faulty before. It was causing DTS to fail(require transcoding) on never firmware. This is now corrected. Also went through the entire capabilities and added full support for every audio codec and limited them by the devices audio channel support. "

 

I am not sure if this has anything to do with what you are saying above.

 

The below was started with autodetec  and it transcoded to ACC

is the codec  DCA a reason???

Convert DTS to AC3 is set to NO in settings

 

Audio

Languageeng
CodecDCA
ProfileDTS
Layout5.1
Channels6 ch
Bitrate1536 kbps
Sample rate48000 Hz
Bit depth24 bit
DefaultYes
TitleEng DTS 5.1 Default

 

 

Audio

Languageeng
CodecDCA
ProfileDTS
Layout5.1
Channels6 ch
Bitrate1536 kbps
Sample rate48000 Hz
Bit depth24 bit
DefaultYes
TitleEng DTS 5.1 Default

[speechles 1929]

I'll test this tomorrow, if needed (commandeering the living room television on Sunday nights is a capital crime around here ).

 

 

I did a quick test earlier and it did fall back to transcoding, but it started on the chapter marker rather than the rough time of the player crash (~60secs beyond the chapter start point, in this case), leading to a replaying of the chapter from the beginning. I only ran one test and started playback at that chapter, so it could've been an oddball occurrence. I'll try playback from the beginning and let it run (crash point is only 22mins in) to see if it does the same, then post an update.

 

Oh, update about eac3: ffprobe doesn't detect 8-channel eac3 properly (returns that it has 6 channels), so Emby doesn't recognise it properly anyway. At least I found an eac3 8-channel audio sample file, so I just generated a blank screen video stream to go with it and will run that test tomorrow as well.

When the fallback happens, all the app is really doing is counting the error, and if less than the fallback retry preference threshold it respawns the videoplayer "m.show()" after setting isTranscoding to true, and the playmethod to "force transcoding". It should resume exactly where the videoplayer caused the error. The index can be off by up to 15 seconds so it should start before the error happens everytime, not after. m.playposition controls where it will resume. When the videoplayer closes it resets the playmethod back to what it was before. So to the novice user what it is really doing when it fails, is choosing "force transcode" and trying again itself. The user no longer has to do this manually.

 

That might explain all the ffmpeg errors I see using eac3. ffmpeg complains about using an outdated version that doesnt support sub-streams. That error floods the transcode log and makes transcoding eac3 to ac3 excruciatingly slow. The error message suggests getting a current ffmpeg from github directly.

 

You can look in capabilities.brs and see the new parts. Both eac3 and flac are always passed as alternate audio codecs to the emby server now. This lets the server use the default audio codec instead, if using eac3 or flac have more audio channels than the device supports. This greatly improves the transcoding logic letting the profile know how many channels every audio codec can handle. The servers profile logic makes much better decisions when you give it more information to work with.

Edited October 24, 2016 by speechles