Jump to content

Chromecast is sluggish


Lighthammer
 Share

Go to solution Solved by Luke,

Recommended Posts

I checked out the other threads on this topic and nothing quiet covers it, so as to not distract from the other topics, I figured a new topic was best.

The problems I'm having with Chromecast is most (not all) videos stream with tons of hiccups; about every 15-30 seconds for most videos.

I have the vast majority of my videos encoded at 480 / 2k bit rate. As often as possible I try to run direct from the files without any transcoding, as I picked this format specifically for its wide range of device compatibility. I have a few remaining videos that are encoded differently such as 720 / 500 bit rate, 1080 / 1k bit rate and a few other standard-ish formats. No format seems to work better then any other, which is confusing as some videos, despite being encoded the same, run better or worse then others.

Where Chromecast is concerned, it seems like the major problem is the server is trying to spend an excessive amount of time transcoding the videos instead of just playing them and there doesn't seem to be any options where Chromecast is concerned to prevent or mitigate this.

Important configuration stuff I have done:

- Path substitutions are set for each and every library entry.

- Each substitution is of course properly shared with proper read permissions.

- I've set transcoding from auto (which was generally working for me) to highest speed.

- On Android, I've set the streaming bit rate to 1.0 mb and the Chromecast bit rate to 1.4 mb (lowest).

- All devices are in the same local network. 

Those are all the major settings I believe I've played with.

 

I feels like the server is spending excessive amounts of time trying to encode files for transmission despite no other device having this problem. Just looking at some of the transcoding options, I notice the formating is different and it leads me to believe that there is a possibility the transcode formats may be incomplete or incorrect where Chromecast is concerned.

For QA purposes, I've used Chromecast with several other apps and everything is working smoothly elsewhere: IE Youtube, Browsercast, Pandora, etc

Link to comment
Share on other sites

Do the same files play OK to the CC from the web client?

 

What BitRate setting do you have set in the Android app?

 

Redshirt will need server, transcoding and app logs for review.

Link to comment
Share on other sites

It runs perfect when streaming from the browser.

 

I already stated what bitrate I am running from Android:

 


- On Android, I've set the streaming bit rate to 1.0 mb and the Chromecast bit rate to 1.4 mb (lowest).

 

Also, I'll toss out that Music streams fine from all Androids on the network, it's just videos that are in question regardless of which Android it is.

As for logs, here they are:

https://www.dropbox.com/s/ghzepzkj68m8pml/logs.zip?dl=0

Link to comment
Share on other sites

Ok, I figured out best settings for my situation that SEEMS to be working. Documenting this for others who may be having problems.
 

-- On Android App -- 

- HLS Support OFF

- Lan/WIFI bit rate and Chromecast bit rate need to match. In this case I am using 1.4 mb/s.

 

-- On Server ---

Advanced -> Transoding

 - Transcoding Quality Preference: Higher speed

 - Audio boost when downmixing set to 2

At this stage, I'm getting responses now. 

 

Err scratch that --- two videos worked perfect running for about 10 minutes each. Then I tried testing several videos (particularly ones that failed the other night or ones in that series) and they all fell flat on their face.

It feels like the server (or maybe the android app) isn't smart enough to realize when you've moved onto to another video and doesn't flush / stop decoding and begins to buffer overflow.

I looked through the logs briefly myself but I don't see much that would even indicate if this is what's happening or not. If there are specific things I should zone into in checking this, please let me know.

Edited by Lighthammer
Link to comment
Share on other sites

Do you only have 1 ffmpeg process running when watching a different video?

 

My CC BitRate in the app is the default of 4mb/s and playback is fine until it randomly stops, which is why v2 of the CC app needs to be implemented in the Android app.

Link to comment
Share on other sites

I only have Media Browser running when these video problems occur.

Media Browser itself seems like its trying to run multiple processes though.

Link to comment
Share on other sites

It's normal for it to lag every 15 - 30 seconds ? =P That's the sort of thing if it was "normal" would cause the technology to be scrapped. Pretty sure that's not the case and we're having a communication problem.

I tried going back to a higher bit rate and it works --- for a few videos --- then has the same lag problem. Rebooting the phone or server DOES NOT fix it, nor does flushing out the transcode folder.

I'm pretty convinced that something in the process just doesn't know how to stop transcoding when shifting to another video. I believe its the Android App that's the problem, but I'm not entirely unconvinced there's not a problem on the server side.

 

Link to comment
Share on other sites

I was talking about 1 ffmpeg process running being normal.

 

Each time a video is stopped, then the client will send a stop signal to end the transcoding.

 

If this isn't happening, then it's a bug.

 

Are you running MBS as a service?

Link to comment
Share on other sites

I am.

 

Also, the video itself is straight stopping on its own too when it seemingly hits the end of what's been transcoded instead of lagging for a duration. it actually straight stops.

 

Saying that the transcode is SUPPOSED to stop when the video is stopped might be something that is compounding the problem. If the transcode constantly stops and starts because the video lagging causes the video to stop instead of buffer, then that would explain why I am seeing things that feel like buffer overruns. 

Link to comment
Share on other sites

just for testing purposes, can you try chromecast with the web client and let us know if it performs better? thanks.

Link to comment
Share on other sites

Already did and yes it does.

 

As far as I can tell there's zero problems streaming from Chrome to Chromecast. 

Edited by Lighthammer
Link to comment
Share on other sites

  • Solution

That's good to know because soon the android, iphone and ipad apps will update to use the new CC that the web client uses, and they will work just as nicely.

  • Like 2
Link to comment
Share on other sites

That's good to know because soon the android, iphone and ipad apps will update to use the new CC that the web client uses, and they will work just as nicely.

 

Awesome. That's what I was hoping to hear.

 

You're responses always make me happy, Luke =).

Link to comment
Share on other sites

just for testing purposes, can you try chromecast with the web client and let us know if it performs better? thanks.

I suggested all of that earlier and he already confirmed it ;)

Edited by CBers
Link to comment
Share on other sites

I suggested all of that earlier and he already confirmed it ;)

 

Yep, though it was a bit burred in our conversation, so I figured it would be faster to just answer (and gave me a chance to double check a few videos, not just one or two)

 

Posts stated:

 

For QA purposes, I've used Chromecast with several other apps and everything is working smoothly elsewhere: IE Youtube, Browsercast, Pandora, etc

 

It runs perfect when streaming from the browser.

Link to comment
Share on other sites

Yea, the current version looks neat, but its obviously prone to a lot of problems.

I'm looking forward to the update.

Link to comment
Share on other sites

I was talking about 1 ffmpeg process running being normal.

 

Each time a video is stopped, then the client will send a stop signal to end the transcoding.

 

If this isn't happening, then it's a bug.

 

Are you running MBS as a service?

 

I have noticed that the server continued to transcode after stopping the video in the client, in fact it happened consistently. I haven't really used the CC much yet though so haven't bothered to capture any logs. I'll test it again when the Android app uses v2, and if I can still reproduce it I'll definitely report it.

Edited by randomizer
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...