Strange chromecast problem

Hi just got a quick query

I’ve been using my WD my cloud to stream videos wirelessly to my TV via a media server for a few years - no problems

I recently bought a chromecast to stream directly from my phone, works great - however some videos which play perfectly directly through the TV from the my cloud do not work/are very choppy when cast via my chormecast.

I am going My cloud - Iphone - Chromecast through either infuse or Nplayer.

As a result I wanted to see what the limiting factor was.

If I put said video on a USB HDD attached to either the mycloud or directly to my 5ghz router and stream through the iphone - it works perfectly no choppy or slow playback like when I put the video on the my cloud.

Therefore it looks like something is going on transfering from the mycloud to my phone and then onto the chromecast.

Is there anything I can do to fix this?

As i say, its not the phone thats the limiting factor, or the network because on other network locations, one even connected by USB to the mycloud it streams no problem…

Any ideas?

Thanks
Andrew

What band is Chromecast connected to – 2.4G or 5G? For best results video needs to be streamed via 5G as it is intended for streaming video because it is faster…

Yes, 5G network - I’ve checked all the obvious things… It seems to be related to the Mycloud somehow or going My cloud --> Iphone --> Chromecast as apposed to Networked HDD --> Iphone --> Chromecast or HDD in mycloud --> Iphone --> Chromecast as it works perfectly on all those 3 scenarios

The chromecast might also lack the processing power to handle the stream, and be stuttering from decoding burden. Any details that might refute or sustain that possibility?

Are there any recurringly consistent features about the videos that are choppy? (All the same codec, all the same bit rate, etc?)

so let me get this straight your wifi streaming a video file thru the internal network then to the chromecast then to your phone.

what you are experiencing i call network shift studder.
first it will buffer to the chromecast from the my cloud then it will buffer from chromecast to the device.
it would be better to reduce the hops and simply find a away to watch the files directly on target device.
i would transcode to the target stream and use that.

something to keep in mind is the chromecast works best with youtube and the like. it certainly does not have the power to xcode on the fly.

It doesn’t appear to be a transcoding problem, or Chromecast processing power problem; note the experiment with the identical file streamed from a USB HDD attached to either the MyCloud, or a router. Therefore, it appears to be some problem with streaming from the MyCloud’s internal HDD. I’m surprised, since that’s a SATA interface, and my experience of the speed of the MyCloud’s USB port is not good; I’d expect the SATA to faster.

I wonder if there is some other activity going on with the internal HDD whilst the video is being played; other devices accessing, media scanning running, etc.

yep there are other process that run in the background on the drive in the drive which i am sure you know CPT.
cron and the like. in my experience it was better to use that (mycloud)-gen 1 has a basic storage device. and usb a local usb 3.0 external drive and a plex media server to handle most of my lifting.

Wouldn’t any cron-initiated services also affect an external USB HDD attached to the MyCloud, if they’re caused by processor activity? If they’re caused by disk scanning activity, then, assuming you have it set to serve media from the external USB HDD, then it will also be scanning the USB HDD.

It’s the discrepancy between internal SATA HDD and external USB HDD that I find odd. It seems to be something peculiar to the internal SATA HDD, so it must be other activity/problem with that.

in regards to external usb drives and the mycloud what is happening is the file being sent to the external drive is first copied to the mycloud then copied over to the external drive the thread below might be of intreset

That thread assumes you are not logging in over ssh.

If you log in over ssh, one can have the mycloud copy directly off the attached USB device. The syntax is something a bit like this:

cp [-R] /shares/[name of connected USB share]/[directory or file to copy] /shares/[destination share]/folder to copy to]

EG;

cp -R /shares/usbstick/* /shares/Public/upload

The bandwidth of the USB3 device is much greater (3gbit) than the wired interface (1gbit), so huge amounts of data could be written very quickly if you dont mind shuttling with a big USB3 device.

that does not help with this issue though. Agreed that it probably is jitter.

Many users have found that moving data to/from a USB hard drive connected to the My Cloud USB port to be slow. There are various past discussions on this slowness issue with the My Cloud USB port with no real solution other than, as the My Cloud User Manual recommends (http://products.wdc.com/library/UM/ENG/4779-705147.pdf#page=97) for copying large amounts of data from/to a USB drive, to connect the USB drive to a computer and copy the data to/from the My Cloud. Obviously making sure to have that computer connected via Gigabit Ethernet to the same router the My Cloud is connected to.

Now I want to do testing with a good USB3 drive. I really cannot see how going over a 1gbit connect would be faster than using a native 3gbit bus, when the copy does not cross the wire. (EG, initiated INSIDE the mycloud, using the console.)

Maybe it might be true if the USB3 implementation of the MyCloud is just garbage-- but really?

I think it probably is garbage.

But that’s getting away from the OP’s problem. The problem is not with USB HDD; that works fine. The problem is with accessing the MyCloud’s internal HDD:

Hmmm… Curious.

WAIT.

… exactly… HOW MANY videos are on the internal HDD, Andrew?

There is a known slowdown issue concerning “very large” video collections, and the indexing service. Do you have SSH access, and or-- know how to use ssh?

Cpt_Paranoia:
The internal HDD is ALSO the default swap disk-- if you see where I am going with this.

Hi all

Reading through the thread has taken a slightly different direction (no problem there) but to bring in back to the last comment and question.

My my cloud has a fair amount of videos - its the 4TB 2TB of which are used, 1TB of that is my itunes server (music) and my lightroom catalog of files (90,000+ photos), then about 1TB of videos, I couldn’t quantity it in file numbers/volumes. Most of the videos are stored on the external USB - 4TB used of 8TB on WD Red drive plugged into a HDD enclosure.

All videos are on the standard media server option in the WD mycloud web interface. non of the photos are media served as this is a backup. I haven’t set up a plex server or anything more advanced like SSH - Not a big expert on what that is other than a server authentication protocol (i think?).

The earlier question - “why not go direct MyCloud to TV then” - thats what I have been doing, but this is a test case to see if I can buy another chromecast for my non smart TVs in other rooms etc or do away with the server entirely.

Thanks for the help and glad its prompted some discussion!

I have no problem playing videos from a MyCloud on an ipad (using FileBrowser app which is capable of casting to a Chromecast) on a non-smart TV. Ya gotta have a fast and effective 5G signal to play the (mp4) videos from NAS and then send on to chromecast (which actually just picks the video off the home network wirelessly) Point is, not everyone has the right equipment and wireless network to do the job.

BTW, I do not actually play videos this way, I just play the original ISO files from NAS on either a WDTV or Fire TV w/Kodi.

I was referring more to THIS:

Basically, the indexing service keeps track of all the media files you have, and tries to keep cached file handles for them in its memory. Since the MyCloud has rather limited memory and does not have the zram swap module baked in (Really, WD— WHY did you do that!?) the device starts having to hit the swap partition pretty hard as the index size grows beyond a certain point-- at least that is the theory.

Since the internal sata disk is the physical device hosting the swap partition, its read and write accesses will be in contention with this disk swapping, which could be the source of your stuttering, and also neatly explain why USB connected disks being shared by the MyCloud are inimpacted. (No swap partitions on those, no I/O contention.)

Was asking about SSH access, because we could get a reading from [free], [top], and [cat /proc/swaps] to see if large amounts of swap are allocated, and by what process.