Amazon Firestick and UMS

[nouse]

I am running UMS 9.0.1 (due to some recent subtitle problems on my Samsung MU, i downgraded UMS) on a Win10 64 Bit System.

Recently, i bought a Amazon FireStick to replace the vastly outdated smart hub of my samsung E-series (alt TV).

I tried several solutions to play UMS-hosted content via DLNA on said firestick:

VLC -> did not find UMS.
Nova TV -> did not find UMS.
Airscreen -> does find UMS. Stutters randomly while streaming. Fast navigation. Does not always find external subtitles.
Vimu TV -> does find UMS. stutters randomly, but less severe than Airscreen. Does not always find external subtitles, most often only after the hosting PC (not UMS!) is restarted, for unknown reasons. Vimu also has a horrible way to navigate through your files.

So far, my results have been far from spectacular. Turned out that my old Samsung via its Allshare App itself plays UMS content more reliably than the Firestick can.

Do you have any advice, in terms of apps i can test or settings i can change in UMS?

This is a general question. I can upload logs if you are willing to check why Firestick apps sometimes ignore subtitles.

How do you solve this problem?

[Nadahar]

It shouldn't really matter what "app" you're running as long as it supports UPnP AV/DLNA. The stuttering issue might be due to limited network bandwidth, or it might be because your PC isn't powerful enough to transcode the file in question. I would have to know more about your setup to guess what is the most probable.

My guess is that there's no good renderer configuration for any of these "apps" in UMS, so things are running under "less than ideal conditions". There's really no reason why these shouldn't be able to do it just fine as long as UMS is configured correctly, unless they are bugged in someway of course - but that seems unlikely for three different applications.

I'm pretty sure that the subtitles issue is caused by the renderer configuration is use. A log would reveal all these things, if you made a log while playing a file with one of these issues. Don't do all kind of different things in one log though, it's just confusing.

The crucial issue here, as I see it, is figuring out the stuttering. I assume the Firestick use WiFi, but I don't really know what WiFi standard it supports. It also depends on your router of course. Anything less than 802.11ac could be problematic.

UMS requires much higher network bandwidth than the streaming services, because it has to transcode in real time. The streaming services have already encoded the videos in advance and just serves them, so they can afford to use much stronger compression. UMS has to stick to something that the average computer can manage in real-time, which means much more bandwidth use. Usually that isn't a problem on a home network, but older WiFi standards (pre ac) are known to be insufficient in some situations (depending on the content).

[nouse]

Thank you for your quick reply.

I should have mentioned that the stuttering only occurs with Firestick, i can play the files with the AllShare App on the TV itself just fine. I tested this several times (recognize the stuttering, switch to the Samsung internal app, and play the same file). I have fairly new hardware (Ryzen 7 2700X) and a Fritzbox 6490 is running WiFi on IEEE 802.11ac, n, g, b, a. The TV runs on IEE 802.11a/B/G and N, but sofar has never been a problem (and currently the Firestick is serving as the WLAN receiver, anyway, which is brand new). Measurement directly next to the TV with my cell phone yielded WiFi bandwidths ~50-70 Mbit.
I will provide a log tomorrow.

Since the firestick is in use, UMS has recognized to new renderers which are running under Google-Android-Chromecast.conf and Google.Android.conf, respectively.


Thank you again for devoting your time. I am feeling i am THIS close to a fully satisfactory solution. What bothers me a bit is the irreproducibility. Sometimes its working like a charm, and just a few hours later, it stops working. And i have no idea why restarting the PC does help with the problem, conceptually.

[Nadahar]

Are you saying that the Firestick IS the NIC also for the TV? As long as you're on ac, you should have no problems - assuming that the Firestick actually delivers that speed. All I know is that they are cheap and that I didn't immediately find any specs, so I assume that the NIC in the Firestick might be of "the budget type". For the primary use, streaming from Amazon, it won't be a problem anyway since the bandwidths are much lower.

It looks like you CPU should have more than enough oomph, so I doubt that's the bottleneck. I have no idea what formats the Firestick actually supports, but I have my doubt that especially the Chromecast configuration will work very well.

There's no point in speculating any further, hopefully the logs will shed some light.

[nouse]

Here are two logs, one with Vimu-App playing, but ignoring external subtitles ("Failed.zip").
Second, a log from a fresh PC session, directly after start, with Vimu-App working flawlessly ("Worked.zip").

(Sidenote: "Failed.zip" also includes some starts with the Airscreen App at the end of the log. Airscreen showed its usual stuttering.)
Interestingly in the "Worked-Log",, although i am using the Vimu-App, the renderer called "AS-AFT[DMR]" is invoked, which actually is the renderer representing the Airscreen-App.

worked.zip

(113.54 KiB) Downloaded 420 times

The attachment Failed.zip is no longer available

Thank you very much!


PS:
As far as i know, the Firestick takes over the WLAN of the TV set.

Edit 2: One observation: If subtitles are working, the files in the Vimu-App navigation are recognized as [Filename][FFMPEG]{Unknown Subtitles}. If the subtitles arent working, the [FFMPEG]{Unknown Subtitles}-part is missing.

[Nadahar]

"Failed" isn't made in "trace mode", so I'm afraid it's useless.

[nouse]

"Failed" isn't made in "trace mode", so I'm afraid it's useless.

Oh my. I am fixing this asap.

[nouse]

failed.zip

(273.76 KiB) Downloaded 449 times

Here is a log file under trace mode. At 09:04, i started streaming, and the subtitles didnt show.

This time, the renderer selected for the Vimu-App, was the "correct" renderer, called "Vimu on AFFT" (Google-Android.conf). Maybe this is the problem?
(To quote from above: "Interestingly in the "Worked-Log",, although i am using the Vimu-App, the renderer called "AS-AFT[DMR]" is invoked, which actually is the renderer representing the Airscreen-App")

[Nadahar]

The reason this works is quite obvious when looking at the log. It's using the completely outdated "Android" configuration, which I don't think will work well with any renderer, Android or not. It basically specifies that almost everything should be streamed and doesn't specify what is supported or not, and says nothing about subtitles support.

The matching is obviously flawed since the "Android" configuration has a much too wide search term (Simply "Android), which makes it match:

Code: Select all

DEBUG 2020-05-09 07:22:00.572 [cling-7] Matched media renderer "Android" based on dlna details "Vimu on AFTT 192.168.178.32 uuid:40bba8e6-f428-4652-b220-2034a5b35d22 GTVBox Vimu Player v4 Media player for [b]Android[/b] TV"

It seems like the renderer software is capable of receiving streaming subtitles, so it should probably work quite well with a working configuration. One must be made more or less from scratch though, and I'm not really up for that.

I think it's high time that the developers take some responsibility on this forum, it should be quite obvious that a renderer profile for Firesticks should exist. Somebody just got to put down the hours to figure out what it supports and not, which might not be an easy task - especially for people that doesn't actually have a Firestick. Documentation is usually sparse, so I guess trial and failure is the most likely route that must be taken.

If you want to try yourself, here is what the renderer software claims to support:

Code: Select all

  http-get:*:image/jpeg:*
  http-get:*:image/png:*
  http-get:*:image/gif:*
  http-get:*:image/bmp:*
  http-get:*:image/pjpeg:*
  http-get:*:image/tiff:*
  http-get:*:image/x-ms-bmp:*
  http-get:*:video/3gpp:*
  http-get:*:video/mp4:*
  http-get:*:video/3gp2:*
  http-get:*:video/avi:*
  http-get:*:video/flv:*
  http-get:*:video/mpeg:*
  http-get:*:video/x-mkv:*
  http-get:*:video/x-matroska:*
  http-get:*:video/msvideo:*
  http-get:*:video/quicktime:*
  http-get:*:video/x-msvideo:*
  http-get:*:video/x-ms-wmv:*
  http-get:*:audio/aac:*
  http-get:*:audio/3gpp:*
  http-get:*:audio/amr:*
  http-get:*:audio/ogg:*
  http-get:*:audio/mpeg:*
  http-get:*:audio/midi:*
  http-get:*:audio/x-midi:*
  http-get:*:audio/x-mid:*
  http-get:*:audio/x-wav:*
  http-get:*:audio/x-ms-wma:*

This is very broad, so I think it's safe to say that this isn't the whole truth. I'm 99,5% sure that you can find format/codec combinations that falls within this that it doesn't support. It does give a fundamental idea of which formats they intended to support though.

I've hacked together a starting point based on the BubbleUPnP configuration (which I assume isn't that far away). You have to adjust the "supported" lines until they actually match what is supported. Everything that isn't "supported" will be transcoded. Place the file in the folder where the other renderer configurations are found, under the UMS install folder.

[nouse]

I am speechless. Thank you for your continuing support. I hope you are not doing this as a hobby

That said, when i change the device config,
the following is added by UMS (its just the device id):

Code: Select all

# Custom Device profile
# See DefaultRenderer.conf for descriptions of all possible renderer options
# and UMS.conf for program options.

# Options in this file override the default settings for the specific Vimu on AFTT device(s) listed below.
# Specify devices by uuid (or address if no uuid), separated by commas if more than one.

Device = uuid:40bba8e6-f428-4652-b220-2034a5b35d22

Is this OK or shall i # it out?