Video Playback/Network Issues


Recommended Posts

OS X 10.5.4 Leopard, I believe I also said this in my post where I did all of the eth0 tests.  This means that I'm connecting to the tower using smb://tower from the Finder->Go->Connect to Server window.  Is this adequate?  Is there any other way to see my tower from OS X?

 

How can I check for these different "packet sizes"?

 

I am using a Netgear Prosafe 8 Port Gigabit Switch, model GS108.  It's a few years old.  Is it possible it could slow down the network without losing any packets or having any errors?

 

I have not tried using a "crossover" cable yet, but I guess that would be the next step--I assume I should get a cat6 crossover cable, remove the nameserver & hosts file information in my GO file (since it won't have the same IP anymore and won't see the router), plug them together, and try and connect as usual.

 

When I ran these latest tests I shut don Vuze, Usenet, and every other computer except the iMac and unRAID.  There's no other network using apps on the iMac running besides Mail and Safari.  I also disabled one of the NICs, as you suggested.

Link to comment
  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

Hi all,

 

Did the test with the cat6 cable direct (as a crossover cable) with a fixed address-still got significant stutter in HD playback and noticeable minor stuttering in SD playback.  Attached is the syslog.

 

I also tried this on a PC, and was unable to watch the HD without stuttering.  Could the cat6 cables purchased from RadioShack be questionable?

 

Next steps?

Link to comment

There's nothing of note different about this syslog, compared to previous, except that a parity check is started.  So long as you were testing playback *after* the parity check had finished or was aborted, then there are no clues as to the stutters.  If you were not aware that a parity check was running, then that would explain the problems.

 

Try the 1 gig file copy test, and that should give you a quick check of cable fitness.

 

I'm not sure I understood you, but are you saying that you see stutter on the PC when playing back the file stored on the PC itself?  If so, then the problem could be bad or poor codecs, CPU too slow, or weak graphics card.  HD playback requires major horsepower.

Link to comment
Could the cat6 cables purchased from RadioShack be questionable?

 

If it were, you would see packet errors in ifconfig.. You can also do a ipconfig/all on the windows machine.

 

There are tools to test your network throughput.

 

I'll try and post a torrent later with the slackware version compiled.

 

http://www.pcausa.com/Utilities/ttcpdown1.htm

http://web2.clarkson.edu/projects/itl/HOWTOS/PCATTCP-jnm-20011113.htm

http://www.pcausa.com/Utilities/pcattcp.htm

 

Link to comment

Thanks for your help--I actually did try it without the parity search and still received the errors.

 

RobJ--what I was trying to say was that my PC, which normally plays HD, also can not (I was checking to see if it was OS X that was the problem).  As far as HD playing power, my iMac normally chews through 1080 without any issue.

 

ipconfig/all on the windows boxes show no issues, just like ifconfig shows no issues, must not be cables.

 

 

 

Link to comment
  • 4 weeks later...

Easiest is to set up unRAID to use a fixed IP address

 

... and the local computer as well... for instance make the UnRaid server 192.168.0.1 and the PC 192.168.0.2....

 

;)

 

For those searching for help in the future, you might want to use something in the 192.168.0.10 to 192.168.0.20 range for static IPs.  x.x.0.1 is normally reserved for the router by default, and when you plug everything back into the network you'll pull you hair out wondering why the network has gone all wiggy. That is, until you remember that you didn't undo the static ip assignment.  I suggest the 0.10-20 range as most routers will also start DHCP assignments at .0.100 and go up from there.

Link to comment

Thanks for your help--I actually did try it without the parity search and still received the errors.

 

RobJ--what I was trying to say was that my PC, which normally plays HD, also can not (I was checking to see if it was OS X that was the problem).  As far as HD playing power, my iMac normally chews through 1080 without any issue.

 

ipconfig/all on the windows boxes show no issues, just like ifconfig shows no issues, must not be cables.

 

 

 

 

Hi there,

 

Don't know if this helps @ all but with my config :

 

MD-1500

Linksys SLM2008

All Molded Cat6

Mac Pro w/ 10 GB of Ram

    Dual Booting Leopard and XP sp3

 

When I stream m2ts files from my server, I sometimes also get very short chops or skips in the video.

As I'm writing this post, I thought of a way to check playback to rule out the computer eg videocard,

going to copy the file locally and just play it back to see if the streaming had anything to do with it.

Link to comment
  • 3 months later...

I have the same issues with video playback.

 

I tried this with unRAID 4.3, 4.4 Beta-2, 4.4 and now I'm running on 4.5 Beta 1.

 

SD videos usually play without hiccups, but not always. HD videos always hiccup/stutter several times at some point in the playback. My unRAID reports no errors.

 

I was wondering if this has to do with SAMBA and if switching my shares over to NFS (as supported by the latest beta) would help. I'm not a Linux expert and since there is no documentation on using the new NFS functionality (other than setting them up using the web interface) I'm at loss. Any help would be extremely appreciated. I don't need detailed instructions, just point me to the right direction and I will figure it out.

 

Thanks.

Link to comment

Just describing media as "SD" or "HD" is not enough info.  Sometimes a HD video can be smaller than the same video in SD, depending on the codec.  I have several HD videos in H.264 that are smaller than the SD DVD of the same movie.

 

For a rough approximation, divide the size of the media file by the time it takes to play to get the bitrate.  So a movie that takes up 4.5 GB and is 92 minutes long would be:

 

49MB/min

815KB/sec

6.5Mb/sec

 

A 24 GB BlueRay version of the same movie would take 5 times as much bandwidth, or 34Mb/sec.

 

Bother are easily doable on Gigabit Ethernet.  The latter would likely cause problems on 100MB Ethernet.

 

You need to check to see that all the NICS are reporting GigaBit connection speed, and are not dropping back to 100MB.  On unRAID, run the command:

 

ethtool eth0

 

Link to comment

I'll take a stab at this, but I'm not an expert, and I'll be going on my recollection of the numbers involved.

 

It's my understanding that almost all hiccups and stutter problems are issues with the playback machine.  There are many causes, but they are usually local to that machine.  Streaming SD or ordinary HD videos is a fairly low bandwidth application, and should be no problem for even a very slow file server or networked device.  As I recall, SD only needs around 3Mb/s, and HD, although it varies much more, may only need something like 8Mb/s.  Neither of those demands very much of your network, and is easily handled even on a Fast Ethernet, let alone a gigabit connection.  So I don't think that the particular OS or protocol should make too much difference.  I believe JoeL has stated elsewhere, when testing his system with IDE drives, he had no issues with multiple streams.

 

We are assuming here that you aren't doing anything I/O intensive on the unRAID server, such as a parity check or writing/streaming TO a parity-protected drive, because that requires 4 times the I/O, than reading FROM the unRAID drive.

 

Video playback is a more demanding application than file transfer.  Transfer speeds often dip up and down, and we don't see that (or care), when copying files.  But when it involves playback, your brain easily notices a momentary dip in the audio or video stream.  Sufficient packets of video and audio information MUST be there, on time, in order to fool your brain into thinking it is watching smooth video and hearing smooth audio.  Stutter is packets that are fractions of a second late in displaying/playing.  That could be because of numerous issues, such as CPU is too slow or working on too many things, such as background processes like security tools, virus detection, etc; or bad or poorly coded codecs and filters and demuxing, or slow audio or display drivers, or ...

 

Generally you want extra headroom, with your CPU, network transfer performance, and other resources.  Playback is usually not at a constant rate, so thinking your network can handle 10MB/s may not be enough.  Some video scenes demand more info to display, than others.  I believe rapid scene changes and intense action require more info.

 

You may also want to time the intervals of stutter.  There are cases of scheduled background processing, that cause a spike in CPU activity, and may very well reduce the CPU availability for a fraction of a second, long enough to notice.  If you determine a regular pattern, then that is a good indicator of a periodic background task, and hopefully the determination of the timed period will help you figure out what is interrupting your playback.  This is only one source of stutter though.

 

[my figures above may not be accurate, may even be the wrong units, I apologize]

Link to comment

Stutter won't come from a packet arriving a fraction of a second too late.  Players buffer content.  If you are getting stutter, your average bandwidth over the buffering interval is insufficient to satisfy the playing of that particular media file.

 

If you copy the file to your local disk, and it plays fine from there, then the network I/O is the likely culprit.

 

You must know the bitrate of the media you are trying to play... both the ones that play w/o stutter, and the ones that do stutter.  By knowing the bitrate of the various media files, you know where the problem bandwidth threshold is.  That can help a lot in troubleshooting.

 

In every case of stutter I've seen, when the server was not busy doing a parity check, or some other I/O was soaking up bandwidth, the problem was 1) cable, 2) switch, or 3) NIC/driver.  Usually, the NIC was dropping back to 100MB.... PARTICULARLY when you can play a 6Mb/sec file but choke on a 20Mb/sec file.... which is why I wanted to know the bitrates of the files.

 

 

Link to comment

I didn't read everything but I would have to agree the any play back issues are probably related to the playing software or the play back machine itself.

 

I can tell you that I play BluRay rips from my UnRaid server (from IDE or SATA) over a 10/100 network with no problems at all, can't tell any difference from having it on the HTPC drive to the UnRaid Server.

 

Sorry I don't know the bit rate. But I just do a full rip of the BluRay to folders, no compression of file conversions of any kind.

Link to comment

I am using Total Media Theater for a player, sorry I can't tell you how much buffering it does. But it is very little time from when you hit play untill the movie starts. Actually the longest time is waiting for UnRaid to spin up the disc, just a few seconds.

 

The network is used for nothing else while we are watching a movie which also helps I am guessing. The hub is a Linksys WRV200, the HTPC has a Gig LAN port but UnRaid is only a 10/100

Link to comment

Bubba - 100Mbps Ethernet can only support a 34Mbps data stream?

 

Has the original poster tried a different player with a higher buffer size setting (VLC maybe)??

 

I'm just guessing but it might be time to try a different network card (try a PCIe card) in the server. Maybe the server network is running off the PCI buss?

 

Peter

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.