Play back issues since change to XFS

[Russ Uno]

A bit of usage info:

I primarily use this media sever, #1 in my sig, to record OTA TV from a MacMini with 2 HDHR (4 1080p channels at one time) also playback 1 previously recorded show then delete it.

Been doing this for about 7 years. About 2 weeks ago I replaced one of my 1TB drive with a 2TB drive and changed the format to XFS from Reiserfs..  Recording was good and playback was flawless but since the change whether it be Drive (which way faster than the older 1TB drive) watching a show is painful with pauses every few seconds. Now is this an XFS issue or a Ram or Network issue. As I said playback and recording was great before the change. Why would XFS cause issues when Reiserfs did not? It also affects the recordings as well. The pauses coincide with the spikes in the storage image. The green area is where my wife stopped playback of her show "Dancing with the Stars" and deleted it.

I'm thinking of swapping ram from my other server as a test.

Any help appreciated, my wife is about to shoot me.

 

 

[Frank1940]

I looked through your diagnostics and nothing stood out as a problem. 

 

The display of network traffic is not quite what I would expect to see.  Those sudden peaks and then the data rate seems to drop to virtually zero.  Of course, the scale was clipped on the left  size so it difficult to tell what the actual variation is...   What I am about to suggest may seem like witchcraft but let's start to eliminate possible reasons for your problem.  Reboot all of the networks switches and the router.  They all contain some sort of a computer with a fair amount of RAM usually running Linux and sometimes random things just 'happen' and they become hamstung.  In any case it only takes a few minutes to try...

 

I seriously doubt if the change to XFS is in any way involved with this type of problem.  Too many of us have made the conversion (I have done both of my servers in the past month) and no one has complained about this sort of problem.  In fact, I would far more expect it from reiserfs as it is basically unsupported since its developer was convicted of the murder of his wife and is now serving a life sentence.  In fact, a few months back one of the folks attempting to support it made a change that resulted in data corruption in a few cases! 

 

 

[Frank1940]

One question.   What happens if you are not uploading data (recordings) to the server?

[Russ Uno]

14 minutes ago, Frank1940 said:

One question.   What happens if you are not uploading data (recordings) to the server?

The fewer show being recorded the better the playback unles the recordings were affected by this issue, which seems to be the Case. Remember these are real time streams not data uploads.

 

[Frank1940]

It appears that you do not have a cache drive for this system  (#1 Home Theater Server?).   Try turning the 'turbo write mode'.     'Settings'  >>>   'Disk Settings'  and then change the "Tunable (md_write_method): "  to  'reconstruct write'.  This will about double the write speed but it requires spinning up all of the disks when writing to the array. 

 

You might consider adding more RAM to this system to provide more memory to cache the incoming data.  (I have never heard of anyone prior to this using their server setup in quite this manner before by requiring real time writes directly to the array of multiple streams.)  A cache drive might be another option.  If you decide on a cache drive for this system, I would suggest using a ssd since you apparently are recording multiple streams in real time and ssd's are ideal for that type of operation.

 

(BTW, your second server is named something else besides 'TOWER', isn't it?) 

[Russ Uno]

Sorry about the image being cut off, I'll post a new one.

Yes, my 2nd server in not "Tower" and only on when backing up my systems and data.

I did have a cache drive in for a while and can't remember why I took it out, must have been a legit reason but I can try again.

What I am doing is not unusual, there are many people doing the same thing, recording multiple live streams.

From my estimates 4 live 1080 streams is ~ 71Mb/Second or 9 MB/Second. Which should not be that demanding.

I do video editing of raw, uncompressed or very lightly compressed, HD video from 1 drive all the time, no issues.

The thing that gets me is this new drive is much faster than the old one, see the attached speed test for Drive 5..

I just thought that maybe the XFS handled saving data differently than Reiserfs.  The saves seem to be in burst as in the spikes.

Thanks, I will try the things you mentioned and see how it goes.

 

 

 

image1.pdf

NewDrive5.pdf

OldDrive5.pdf

[Frank1940]

What you say is true but, in some cases, those tuners are in a Docker.  Those are the ones that I have heard about.  With the normal disk writing mode (i.e., read/modify/write) there is a lot of activity on the parity disk.  It could be that adding a second disk format into the mix now requires more memory and thus there is less available RAM for buffering the incoming data.   Obviously, unRAID has to be designed so that it doesn't lose incoming data even if this means that the outgoing data stream is interrupted.  Remember in this case, you are requiring that up to five independent streams be handled in real time.  It may take a bit of system optimization to get you where you want to be. 

 

Have you had a look at the 'Dashboard' tab and under the 'System Status' looked at the 'Errors' in the drop-down box?  Particularly the Network section...

 

You also realize that you are still running an old release.  I am not sure there were any changes made that might help with your situation.  But it is another factor. 

[Russ Uno]

Update:

1. I upgraded to v6.2.4 since it looked to be stable, never like to live on the edge.

2. I added a cache drive, an older slower drive but by my calc more than fast enough to record 4 x 1080 streams at a time in real time at 71Mb/s.

The playback of the recorded shows with this setup played back flawless, previously recorded shows played back fine as well unless the recordings were affected buy the issue I was having. But there was no stuttering and pausing of playback in any case.

One issue I have with the Cache is, and I believe this is why I originally removed it is, that if I pre-program shows for the following day(s) or weeks the mover will move them as well as the already recorded shows of that day to the array then they will go back to recording to the array.  Also the first morning I checked the cache drive there was still 12gb of shows that never moved. I believe that was due to the app used for recording, EyeTV, was still up and running and the shows 'appeared' to be still in use when the mover moved. So the next night I had the MacMini & EyeTV shut down before the mover moved and all the shows on the Cache were moved to the array.

However I think the the big part of the problem may have been a memory leak in v6.1.9 because if you look at the v6.1.9 screen shot the ram is maxed out and when playback is started and ram usage is a lower level  but it eventually creeps up until maxed out and stays there. But with v6.2.4 the memory never maxes out, see the green area. This was after 4 hours of use. The effect I was seeing in the recording looked like an issue that involved collisions of the data whether network or ram.

I may try without the cache just see if the memory issue changes.