I've tried multiple PC's. Tried different switches/hubs/routers. Soon as I start to copy a file to unraid my MP3 stops/stutters big time. Soon as I cancel the copy, back to normal.

My unraid server has 14 WD Black Drives 7200rpm, 8GB of ram and a dual-core E8500 processor. I do not think it is the hardware. My end Windows computer was a i7 dual-core laptop with 8GB of ram and an SSD drive. If I copy the music files to another computer and do the same test nothing drops out.

 

While it sounds fast and modern, would you mind listing your hardware for us, and attaching a syslog?  I'm wondering if your busses are fast enough, and especially if there are too many things contending for the PCI bus.  In particular, if you had a disk controller on the PCI bus AND your network card, and were simultaneously accessing multiple hard disks on that controller plus network traffic, you could easily see latency issues.  This used to be a common issue, but lately most users have motherboards and cards using the PCIe busses.

Here is information on my unraid box. The hardware itself has been very stable, and let me remind you this particular issue didn't happen when I was running 4.7. That was a very stable version for me.

 

unRAID Version: unRAID Server Pro, Version 5.0-rc3

Motherboard: Intel - DQ35MP

Processor: Intel® CoreTM2 Duo CPU E6750 @ 2.66GHz - 2.666 GHz

Cache: L1 = 4096 kB  L2 = 32 kB  L3 = 32 kB 

Memory: 8 GB - DIMM0 = 667 MHz  DIMM1 = 667 MHz  DIMM2 = 667 MHz  DIMM3 = 667 MHz 

Network: 1000Mb/s - Full Duplex

Vendor: Intel Corp.

Version: JOQ3510J.86A.1143.2010.1209.0048

Release Date: 12/09/2010

Runtime Size: 64 kB

ROM Size: 4096 kB

Characteristics: PCI is supported

BIOS is upgradeable

BIOS shadowing is allowed

Boot from CD is supported

Selectable boot is supported

EDD is supported

8042 keyboard services are supported (int 9h)

Serial services are supported (int 14h)

Printer services are supported (int 17h)

CGA/mono video services are supported (int 10h)

ACPI is supported

USB legacy is supported

ATAPI Zip drive boot is supported

BIOS boot specification is supported

Function key-initiated network boot is supported

Targeted content distribution is supported

Socket Designation: CPU1

Type: Central Processor

Family: Core 2 Duo

Manufacturer: Intel® Corporation

ID: FB 06 00 00 FF FB EB BF

Signature: Type 0, Family 6, Model 15, Stepping 11

Flags: FPU (Floating-point unit on-chip)

VME (Virtual mode extension)

DE (Debugging extension)

PSE (Page size extension)

TSC (Time stamp counter)

MSR (Model specific registers)

PAE (Physical address extension)

MCE (Machine check exception)

CX8 (CMPXCHG8 instruction supported)

APIC (On-chip APIC hardware supported)

SEP (Fast system call)

MTRR (Memory type range registers)

PGE (Page global enable)

MCA (Machine check architecture)

CMOV (Conditional move instruction supported)

PAT (Page attribute table)

PSE-36 (36-bit page size extension)

CLFSH (CLFLUSH instruction supported)

DS (Debug store)

ACPI (ACPI supported)

MMX (MMX technology supported)

FXSR (FXSAVE and FXSTOR instructions supported)

SSE (Streaming SIMD extensions)

SSE2 (Streaming SIMD extensions 2)

SS (Self-snoop)

HTT (Multi-threading)

TM (Thermal monitor supported)

PBE (Pending break enabled)

Version: Intel® Core2 Duo CPU E6750 @ 2.66GHz

Voltage: 1.6 V

External Clock: 333 MHz

Max Speed: 4000 MHz

Current Speed: 2666 MHz

Status: Populated, Enabled

Upgrade: Socket LGA775

Configuration: Enabled, Not Socketed, Level 2

Operational Mode: Write Back

Location: Internal

Installed Size: 4096 kB

Maximum Size: 4096 kB

Supported SRAM Types: Asynchronous

Installed SRAM Type: Asynchronous

Error Correction Type: Single-bit ECC

System Type: Unified

Associativity: 16-way Set-associative

Cache Information

Configuration: Enabled, Not Socketed, Level 1

Operational Mode: Write Back

Location: Internal

Installed Size: 32 kB

Maximum Size: 32 kB

Supported SRAM Types: Asynchronous

Installed SRAM Type: Asynchronous

Error Correction Type: Single-bit ECC

System Type: Instruction

Associativity: 8-way Set-associative

Cache Information

Socket Designation: Unknown

Configuration: Enabled, Not Soc

Supported ports: [ TP ]

Supported link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Supports auto-negotiation: Yes

Advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Advertised pause frame use: No

Advertised auto-negotiation: Yes

Speed: 1000Mb/s

Duplex: Full

Port: Twisted Pair

PHYAD: 1

Transceiver: internal

Auto-negotiation: on

MDI-X: off

Supports Wake-on: pumbg

Wake-on: g

Current message level: 0x00000001 (1)

Link detected: yes

syslog_opentoe.zip

Here is information on my unraid box. The hardware itself has been very stable, and let me remind you this particular issue didn't happen when I was running 4.7. That was a very stable version for me.

 

I did remember that you had previously said v4.7 worked better for you, but from long experience with troubleshooting computers, when you run into a difficult problem, it's always best to make sure you have covered all the basics, no matter how embarrassing the question.  And that often means going all the way back to "is the power cord plugged in?  both ends?!"  So in your case I felt I needed to make sure of basic I/O capabilities, especially since so far, we don't have almost anyone else with the same issue, at least not to the same degree.

 

As far as I can tell, there is no usage at all of the PCI bus, so that rules that out.  Your system is PCI Express 2.0 based, and everything appears to be using PCIe channels, including the e1000e-based networking, a very good thing!  I did note 2 things, worth a comment below, but I suspect they too are not responsible for your issue.

 

You have an mvsas-based controller card, and in theory support for it should be much better in 5.0-rc3 than 4.7, but I noticed that in 4.7 mvsas claims "mvsas: driver version 0.8.4", whereas in 5.0-rc3 it is "mvsas: driver version 0.8.2".  I'm hoping Tom will have a moment to comment on that.

 

I noticed in your current syslog the line "device eth0 entered promiscuous mode", and looked above and found you are loading the libpcap package.  I don't know enough to say what the network impact of that is, but it should be easy enough to temporarily uninstall it and re-test your issue.

I get this too, vlc or quicktime player on macosx 10.6.8. Just copied the mp3 off the nas and played locally.

You have an mvsas-based controller card, and in theory support for it should be much better in 5.0-rc3 than 4.7, but I noticed that in 4.7 mvsas claims "mvsas: driver version 0.8.4", whereas in 5.0-rc3 it is "mvsas: driver version 0.8.2".  I'm hoping Tom will have a moment to comment on that.

 

Right, that's something interesting.  The mvsas driver in the mainline kernel is indeed 0.8.2.  The mvsas driver in the linux SCST project is 0.8.4.  I believe the same guy wrote both (Andy Yan at Marvell).  The drivers are similar.  The history is this: at some point during 4.x, the supermicro card became available.  The stock mvsas driver at that time did not work reliably, so I incorporated driver from SCST.  The situation remained like this up to 4.7.  Sometime during 5.0-beta, the mvsas driver in the linux kernel had some work done on it, so I switched to using that one, and lo and behold it worked ok (for me).  That brings us up to present...  I will be creating a release called 5.0-rc4-scst-1, which is a test release that replaces the stock mvsas driver back with the one from SCST.  People running with the Supermicro card should try this release (runs ok for me here as well). In meantime, I'll try and communicate with Andy to find out what's up.

 

This probably has nothing to do with mp3 stuttering however 

I noticed in your current syslog the line "device eth0 entered promiscuous mode", and looked above and found you are loading the libpcap package.  I don't know enough to say what the network impact of that is, but it should be easy enough to temporarily uninstall it and re-test your issue.

 

It shouldn't have much of a network impact, it allows "all" traffic to the CPU of the server, but doesn't cause high CPU usage(barely any actually) and it does nothing with packets not addressed to the server. Promiscuous mode simple allows all packets through, doesn't affect the output(to my knowledge). And libpcap is loading for the darkstat plug-in I just released a few days ago, so I doubt it is affecting the issue at hand.

 

Good call though RobJ, I meant to pass the argument so darkstat didn't operate in promiscuous mode but neglected to add it, I'll go do that now. No need for the plug-in to monitor all traffic, only the traffic to/from the server,

I'm running RC4 now. Has the 5.0-rc4-scst-1 come out yet?

 

 

Just to let you know this still happens in RC4. Just tested it out on two different computers.

 

 

I've noticed glitches like this over different versions of unRAID for quite some time.  Some examples are:

 

1. MP3 stream skipping while simply navigating to an unRaid drive in Win Explorer

2. Video stream completely stopping  during a file transfer to a share on the server

 

When I get home I try a couple of these and catch the log.

 

 

 

That's the problem, nothing shows up in the log. Since I am ALWAYS playing music from my unraid server, I've done it this way with version 4.7. all the time. My hardware hasn't changed, but the unraid version. Hopefully this will get taken care of eventually. Thanks.

Any word on this? I'm surprised there aren't more people indicating this issue. Maybe I'm the only one that plays MP3's from my unraid box? Ha.

 

 

I have this issue as well - it is frustrating because there don't seem to be any specific problems in the log.

 

It usually occurs for me when I am playing music, and copying several files at once or when multiple users are connected.

Maybe I'm the only one that plays MP3's from my unraid box? Ha.

 

Hardly.  I often have my Squeezeboxes playing mp3s for 24 hours continuous, with Logitech Media Server running on unRAID.

no issues here. I'm on 4.7 though.

 

i've done 2 1080p streams while CouchPotato is moving files to the user shares and have had zero interruptions.

 

I think i'll stick w/ 4.7 and justify that with the old "if it ain't broke" reasoning

no issues here. I'm on 4.7 though.

 

i've done 2 1080p streams while CouchPotato is moving files to the user shares and have had zero interruptions.

 

I think i'll stick w/ 4.7 and justify that with the old "if it ain't broke" reasoning

 

I had no issue when I was on 4.7 either. This is why I posted this in the unRAID OS 5.0-RC forum area.

 

 

I just had this happen to me a couple minutes ago.  I was listening to some MP3's that are on my unRAID server and I started to rip a DVD to that same server and as soon as the rip started the MP3 playback paused for about 6 seconds and then continued.  I checked the log and there isn't a single entry anywhere near the time that occurred.  It's not a network congestion problem either because I had been listening to MP3's for the previous hour or so and I during that time I copied a movie to a different unRAID server on my network and MP3 playback never missed a beat.

 

I would love to see this get resolved as it's annoying.

 

I am running 5.0 beta 12a

 

EDIT:  I have ripped another 4 DVD's and it happens every time..

 

I'm able to reproduce this on unraid 4.7, and have noticed it for a long time -- just sort of accepted it as the price of doing business, though it is quite annoying.  This thread finally inspired me to do a little deeper digging.

 

Please excuse the verbosity, just wanted to make sure I fully and accurately captured the causes/symptoms.

 

Environment (thoroughly non-standard): unraid 4.7 installed on a full slackware 13.1 installation (running from an IDE drive). 5 modern SATA drives (1.5 - 2TB each) in unRAID array connected directly to motherboard SATA headers. AMD Phenom II X2. No cache drive.  All disks manually spun up prior to the test.

 

For the tests below, I made a point of playing a different mp3 each time (in VLC, per the OP), to minimize disk caching effects.  I've noticed this with video playback at times in the past as well.  The "skipping" causes no syslog entries, nor any noticeable spike when monitoring 'top'.

 

I'm using Teracopy to copy the files over the network.  My writes are typically sustained around 25-30MB/sec (while mp3 is concurrently playing back and not skipping).  When the mp3 playback skipping occurs, the transfer rate reported by Teracopy drops to 5-7MB/sec.  The skipping typically occurs several hundred MB into the transfer, and also sometimes occurs immediately after hitting 'cancel' on the Teracopy transfer (presumably the delete of the half-copied file?).  Overall operation modes seem to be either: skipping (1-5 second pause, accompanied by low write speed for the same duration), and running fine at full speed (25+MB/sec transfer, no playback issues). Haven't noticed an 'in-between' ground.

 

The MP3s being played are in the 3-10MB range at 128-192kbps (an exceptionally low data transfer/processing rate for modern hardware).

 

Network is wired gigabit lan; ifconfig reports no errors/drops/collisions.

 

Playing music over the network via user share (data on disk4), writing a ~1GB file to unraid over the network to user share: skips

Playing music over the network via disk4 disk mount, writing a ~1GB file to unraid over the network to disk4 mount: skips

Playing music over the network via user share (data on disk4), locally copying a file from one user share to another user share: unaffected

Playing music over the network via user share (data on disk4), locally copying a file from disk2 to disk4 (via disk mounts):  unaffected

 

Finally, I manually created a share on my IDE drive (non-array drive) to test (if you're copying files to set up this test, don't forget to do something like "sync; echo 3 > /proc/sys/vm/drop_caches" to clear the cache).  I have only 1 IDE drive; hdparm unbuffered read test on it returns around 55MB/sec

Playing music over network from non-array samba share, writing a large file to non-array samba share: skips  <----- indicates this is very likely not the fault of unraid, its driver, or its software

Playing music over network from non-array samba share, writing a large file to unraid user share: skips

 

 

Based on the above, I am inclined to suspect the network infrastructure/drivers/etc or Samba as the culprit (either Samba itself, or the way in which unRAID sets up the samba configuration), since it never happened unless both operations were happening across the network, and the issue seems agnostic to the underlying storage. 

It's entirely possible my Slackware installation has a different Samba version than standard unraid 4.7 which may have introduced this issue. 

 

"/usr/sbin/smbd --version" returns "Version 3.5.2" for me.

It most likely is a software related issue. My hardware is basically all new and all of mostly high end and good performing. 1000mbit network all the way through. I've just come to the conclusion I can't listen or watch videos streaming from my unraid server and perform copy/move functions at the same time. Kind of a hard thing to swallow for a server type based machine, but what can you do.

Does it matter if the media being played is on the same share or same disk as where the file operation is taking place?

 

Something must be suspending activity.

 

Does deleting a large file cause the same problem? I'm thinking this might be another Reiserism.

 

 

I've already tried using disk or user shares. The same result. I've never tried it while "deleting" a file. Would have to be a pretty big file if I were to test this with. Since it is a disk activity I would assume the same result will happen.

I hate to revive such an old thread, but this problems still exists and I thought it better to revive this thread with it's examples than to have to explain it all again. For me this began as a very minor annoyance, but it has grown into something that is starting to peeve me off.  Not that it has worsened mind you, but it's like someone tapping you on the arm.  At first you don't mind at all, but after a while it starts to hurt.  Years later (I know this thread isn't years old, but the problem is) and I still have to deal with pauses in streaming audio/video if I access, write to or delete from the array. 

 

Is there any hope that this will be looked into and maybe even fixed?

RockDawg,

 

Well you really should start a new thread. As the OP's issues are not yours though your symptoms are the same.

 

Please open a new thread and when you do that, describe your network, is it wired, wireless, powerline, or a combination of all of these etc.  Is it 10mb, 100MB, 1GB.  What brand switches are you using.  are you using cat 6 cable, cat 5e etc, What operating systems are in use.  describe your unraid server, what version, processor, ram, number of drives, and also provide system logs for us to look at.

 

How are able to reproduce the problem, describe how you reproduce the problem.  Go through these tests, do use the OP as your description just to be lazy.  Provide as much detail as possible.  You have an excellent resource available to you, use it to your advantage.

 

Above all ** DO NOT use this thread **

 

:-)

 

--Sideband Samurai

The OP issues are the same as mine.

Really?  Its always good practice to open a new thread.  THAT is the general rule on ALL forum sites.  As an example, the OP was using release 4.7.  Also the OP's hardware is different than yours.  For those reasons and others you should post a new thread. 

 

The advantage to that is your solution will be easier to find instead of buried in another thread. That helps others, not just you. Not only that but that also follows the policy of this forum.  When you open your own thread, there is nothing stopping you from referencing this one, and answering all the questions I posed to you in my last post.  We really need to know about your unraid system and something about your network.  We are not mind readers you know.