Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CHaun]

Is it possible to record tv to a different directory than the one for time shift? I would like to keep time shift on an SSD and record TV to a mechanical drive.

When I had everything pointed to the mechanical drive, I was getting problems with using 3 or 4 tuners at the same time. It seemed like the hard drive could not keep up. The SSD is too small on its own to hold very many recordings.

I thought I had it beat by running a script that moved the recordings from the SSD to the mechanical drive nightly, but I find that is causing duplicates of episodes since mc only checks for episodes on the SSD before recording them.

[Yaobing]

It is not possible at this time.

[CHaun]

It's a shame. Thanks though! =)

[CHaun]

As a work around, is there any way to have mc look at both the recording directory and the long term storage directory before deciding whether to record an episode?

[RoderickGI]

It's probably not a good idea to record to an SSD with the current level of technology anyway. You are bound to wear the SSD out much faster. Although as some will point out, it will still take a long time. But the nature of TV recording, with lots of writes, deletes, new writes, etc., is not really good for an SSD.

A hard disk on the other hand should handle it no problem. Unless you are recording some UHD broadcasts, which certainly aren't common if available at all. What is the highest bitrate that you see recording per channel? The highest I see is a bit under 16Mbps, or 2MB/s. Even if each of your four channels use four times that bitrate at 8MB/s, with four tuners recording that would give you a hard disk write of 32MB/s. Almost any SATA II hard drive can write at 100MB/s, and sustain 60MB/s these days.

So, unless you are using an old hard drive it is unlikely that the hard drive is the bottleneck. Watch the Resource Monitor when you are recording four channels, and see if your disk, CPU, or memory are being maxed out. Or any other resources. Then you may be able to solve the real problem.

[CHaun]

I have attached a screen shot of 3 tuners running live TV to 3 different clients (3/6 tuners used) recording to the mechanical hard drive. While I agree that a mechanical drive should handle this, it seems like one or more of the writes in an alternating fashion seems to hold an elevated spike, possibly from trying to keep up with the concurrent streams. Adding a fourth stream causes gridlock on the drive. These spikes do not occur with the SSD on the same controller.

My system specs are:

Windows 7 Pro x64
ASRock B150M Motherboard
Intel Core i5-6600
16GB Ram
Intel 530 Series 240GB SSD
WD Black 5 TB Hard drive

[Yaobing]

I assume you record in TS format because that is when recording will have extra writes in addition to time-shifting.  If you use JTV format, then recording basically is time-shifting.  No extra writing happens for recording.

To answer your question of MC determining a show is already recorded, we do not actually check the actual disk files.  We check MC database entries for recorded shows.  So it does not matter.  You can, from within MC, move recordings to another hard drive after recording is done.

[RoderickGI]

Yaobing has a good point, and highlights another great reason to use JTV format recording, which I do. Using TS format recording you are doubling the disk load.

The screen shot you posted shows spikes in disk load, but the scale only shows up to 10MB/s, which is not a heavy load for a modern hard disk. Some of those spikes do hit the 10MB/s limit though, so I guess they could be much higher. Do you know how high those spikes go, and what the disk load does when gridlock occurs?

Aside from that, your PC specs are great. The WD Black is supposed to support 194MB/s sustained, so your 10MB/s is nothing to it. Although WD Blacks aren't really designed for continuous writes like an Audio-Video drive, such as the WD AV. I use WD Reds myself, and haven't seen the problem. But I haven't been running four recordings at once to my knowledge. Perhaps I will give that a test to see what happens.

As your CPU load is also pretty low, I would be looking for information about the WD Blacks overrunning their cache (which is large at 128MB, but maybe the drive handles data differently and tries to accept all data into the cache, rather than manage the data flow as an AV drive would), and looking for any stories about the ASRock in a AV or HTPC or perhaps better, surveillance application. I assume you have them set up using AHCI, and are taking advantage of all the latest technologies in the drive?

Also, I see your network spiked up to 100Mbps twice, and the load remains quite high. You don't say what tuners you are using, but if you are using network tuners and for some reason your network is running at 100Mbps instead of 1Gbps, then there is your problem right there. You need a 1Gbps network to handle those spikes.

Also, I know you said that it all works when writing to the SSD, and doesn't with the hard drive, but that shouldn't make a difference really, with your hardware, unless some of the hardware has a problem. One difference I could think of for the SSD and HD is if you are using a SATA III port on a different chipset for each of them. If so, move the HD to a SATA port that uses the same chipset as the SSD and see if the problem goes away.

Let us know how you go with the above.

[CHaun]

I'll move the record back to the SSD and move the data nightly since that is supposed to work. If the writes start to get too crazy, I'll probably drop in a dedicated intel dc s3510 ssd.

On the screenshot, none of that was actual scheduled recording, those were live TV being fed to 3 network clients and the subsequent time-shift writing. With a fourth tv feed, there is constant stuttering and freezing on clients. Unless there is some way to timeshift in jts and record in ts, I have to keep it ts since I plan on implementing comskip eventually on recorded series.

I have some WD reds on an adaptec controller that is storing the movies. I might try and see how that fares, but the adaptec is a lower end 6405e so it may not do any better.

I'm very new to this program, but things on the whole are going way better than I could have imagined. Thanks again for all the help and ideas!

[RoderickGI]

On the screenshot, none of that was actual scheduled recording, those were live TV being fed to 3 network clients and the subsequent time-shift writing.

Ah. Well that changes the situation quite a bit, as the MC server is going to be Time Shifting each channel, writing the Time Shift files, then serving them to clients with buffering and possibly format conversion going on, depending on your client settings. Only Yaobing or other JRiver developers could comment sensibly on what might be the issue there.

Certainly your screenshot doesn't show any serious load on anything, except maybe your network. On looking at the screenshot again I see that your network is loaded at 7% with 73Mbps throughput. So it looks like you do have a 1Gbps network. So it should be fine, unless those peaks are big enough to cause the stuttering you see. If your graphics card is doing some work (i.e. hardware acceleration) in serving up or converting the live streams, it could be the problem. Check the GPU load with four channels playing.

I don't have four clients to test that type of load on. But I did test recording four channels at once on my internal PCIe quad tuner, and that worked fine. I did notice though that my recordings only received an I/O Priority of "Background", while MC's Audio Analysis and Thumbnail generation were getting "Normal" I/O Priority! That doesn't seem right. However, your Time Shifting files are getting "Normal" I/O Priority so there is no issue there.

Unless there is some way to timeshift in jts and record in ts, I have to keep it ts since I plan on implementing comskip eventually on recorded series.

Either you misunderstood or mistyped that. When you record in JTV format, Time Shifting and Recordings use one JTV file set. When you record in TS format, Time Shifting is in JTV format, and recording is in TS format, and written in parallel to the Time Shifting files (not converted later).

If you are just having a problem when four Clients watch TV live, with Time Shifting, then only JTV file sets are involved. You should test if you still have the stuttering problem when four MC Clients play back four separate (different) HD recordings. I suspect that you won't have a problem, as long as you aren't also recording several programs while playing the recordings.

As an aside, while JRiver haven't provided a method to quickly re-mux JTV files to TS files, while retaining all the quality, I have written up how it can be done. It is a manual process, but if you are recording stuff to be watched at some later time, you could possibly record in JTV format and then convert to TS to run Comskip, or you could use VideoReDo TVSuite V5, like I do for movies and a few other programs.

I have previously written how to do the JTV to TS re-muxing here: http://yabb.jriver.com/interact/index.php/topic,105793.0.html

I'm also trying to get the folk at VideoReDo to directly read JTV file sets, and they are showing interest again in doing that, after a couple of years waiting. 

I have some WD reds on an adaptec controller that is storing the movies. I might try and see how that fares, but the adaptec is a lower end 6405e so it may not do any better.

I'm thinking less and less that this is a HD vs SSD issue, and more that it is a network or MC problem. Other users have had some issue when streaming live TV to multiple MC Clients, and to date there hasn't been one ah ha! solution found to some on those issues. Often they do seem to be installation dependent, and therefore there is no universal solution. But I'm think maybe MC has some efficiency issues in this area. So keep on testing, providing information and trying to solve the problem, if you can, and Yaobing may find the cause.

I'm very new to this program, but things on the whole are going way better than I could have imagined. Thanks again for all the help and ideas!

Yeah, it is a good program. Not perfect, but what software under constant development is? Aside from the issue of availability of client software for all platforms (Android, iOS, Windows 10 Phone, TVs, Apple TV, media boxes, etc.) I still see it as the best HTPC software available.