TV server - freeze (2 Viewers)

[Phaedra]

Status update.
Yesterday, after several days of testing, things went badly wrong again.
The last days, I noticed some tv channel freezing that would not be acceptable for a live TV configuration. Even recordings stopped after a while, making the system unusable for day to day TV watching / recording.
Yesterday evening, coming home, I started the client and selected a HD channel. This went very well for over an hour, after which I switched channel. This started a new episode of freezing on several channels, gradually getting worse, until I got no signal on any channel anymore.
Going to the server, starting a scan, no signal was found. Tried other DVB software, same result : no signal.
That sounded familiar ; it seems to happen at regular intervals.
So, instead of sleep / wake the server, I did a cold reboot, and everything went back to normal.

Conclusion : somewhere, somehow, inbetween cold reboots, something "builds up" which seems to cause my DVb card to malfunction (since no DBV software can get it to tune channels anymore).

Maybe I should try to reproduce this via sleep / wake cycles, and endurance tests with HD streaming.

 

[Phaedra]

Update.
Apparently, I have been dealing with two separate problems : the channel freeezing, and the loss of signal after sleep/wake cycles.
1. Channel freezing
Since this only appears in Mediaportal, and not in other software, it must be a software problem. I have re-applied the patch as before, and now I have been testing for three hours without a glitch. Before the patch, the system would never last for more than 20 minutes before freezing. I will continue further setup and testing of my system with this patch applied.

2. Sleep/wake
Tis seems to be totally software-independant : I have the same problem irrespective of DVB software used, and it seems to return consequently after a number of sleep/wake cycles.
Browsing the forum of the DVB card manufacturer, it seems that I am not he only one experiencing this sort of problem. Still waiting for an answer though...
Meanwhile, I will be looking in the devcon.exe direction to schedule a restart of my DVB card upon a wake event. If I can get that working, I should be able to get rid of this problem too.

Next is EPG grabbing, will be trying "For The Record" as an alternative.

Living on high hopes...

 

[mm1352000]

Hi again Phaedra

Update.
Apparently, I have been dealing with two separate problems : the channel freeezing, and the loss of signal after sleep/wake cycles.

Hmm, interesting. I thought you said the loss of signal just randomly happened and that you saw it happening when the TV timeshifting froze...

1. Channel freezing
Since this only appears in Mediaportal, and not in other software, it must be a software problem. I have re-applied the patch as before, and now I have been testing for three hours without a glitch. Before the patch, the system would never last for more than 20 minutes before freezing. I will continue further setup and testing of my system with this patch applied.

If you take channel freezing or stutter as a problem in isolation of the other symptoms you described then the stuttering patch (included in 1.2.0b) is a good thing to try. It looks like you're using a 1.5TB HDD. I'm only guessing, but since most 1.5TB drives are ~5400rpm "green" drives, I suspect your HDD is a "green" drive too. Those slower HDDs are quickly building a reputation for causing trouble. MediaPortal has quite high I/O requirements on the HDD, and non-7200rpm drives often can't cope. Especially if they are the OS drive or being used for other things at the same time. I suggest you keep using the patch. You could also try setting up a RAM drive for timeshifting since you have 4GB of memory...

2. Sleep/wake
Tis seems to be totally software-independant : I have the same problem irrespective of DVB software used, and it seems to return consequently after a number of sleep/wake cycles.
Browsing the forum of the DVB card manufacturer, it seems that I am not he only one experiencing this sort of problem. Still waiting for an answer though...
Meanwhile, I will be looking in the devcon.exe direction to schedule a restart of my DVB card upon a wake event. If I can get that working, I should be able to get rid of this problem too.

Yeah, like I said earlier this is a common problem. Nothing can be done to properly fix the problem except by the driver engineers. The best you can do is devcon. I have a similarly annoying problem with my tuners - they do bad things when there are more than 4GB of RAM in the system...

 

[Phaedra]

Update.
Apparently, I have been dealing with two separate problems : the channel freeezing, and the loss of signal after sleep/wake cycles.

Hmm, interesting. I thought you said the loss of signal just randomly happened and that you saw it happening when the TV timeshifting froze...

Yes, in TV server configuration, when doing manual timeshifting, I saw the signal dropping. When stopping and restarting timeshifting, everything was normal again.
But the "no signal" problem is another issue : by that I mean that I get no signal on any satellite or any transponder, no matter which software I use.

If you take channel freezing or stutter as a problem in isolation of the other symptoms you described then the stuttering patch (included in 1.2.0b) is a good thing to try. It looks like you're using a 1.5TB HDD. I'm only guessing, but since most 1.5TB drives are ~5400rpm "green" drives, I suspect your HDD is a "green" drive too. Those slower HDDs are quickly building a reputation for causing trouble. MediaPortal has quite high I/O requirements on the HDD, and non-7200rpm drives often can't cope. Especially if they are the OS drive or being used for other things at the same time. I suggest you keep using the patch. You could also try setting up a RAM drive for timeshifting since you have 4GB of memory...

That's exactly what I intended to try too.
The 1,5 TB drive is a pure data drive ; my OS is on SSD, applications are on a separate 300GB HDD. But a RAM drive can't be beaten for timeshifting. If the HDD is a problem, then I have to see how I will go about recording (which could prove difficult on a RAM drive.... )

2. Sleep/wake
Tis seems to be totally software-independant : I have the same problem irrespective of DVB software used, and it seems to return consequently after a number of sleep/wake cycles.
Browsing the forum of the DVB card manufacturer, it seems that I am not he only one experiencing this sort of problem. Still waiting for an answer though...
Meanwhile, I will be looking in the devcon.exe direction to schedule a restart of my DVB card upon a wake event. If I can get that working, I should be able to get rid of this problem too.

Yeah, like I said earlier this is a common problem. Nothing can be done to properly fix the problem except by the driver engineers. The best you can do is devcon. I have a similarly annoying problem with my tuners - they do bad things when there are more than 4GB of RAM in the system...

Do you mean that you also run devcon on wakeup ? You do it the way I described, via a scheduled task, or is there another way ?

Another thing : the delayed start for the TV service could be annoying, because it takes a while after wakeup before the service kicks is. In a WOL situation, this could cause the client to complain, or the rest of the family for that matter...
On the other hand, if I have to run devcon on wakeup, I reckon I don't really have a choice but delaying the TV service...

 

[mm1352000]

Hi again

Yes, in TV server configuration, when doing manual timeshifting, I saw the signal dropping. When stopping and restarting timeshifting, everything was normal again.
But the "no signal" problem is another issue : by that I mean that I get no signal on any satellite or any transponder, no matter which software I use.

So we are guessing that:
- the "dropouts" (signal dropping when manually timeshifting) are probably due to HDD issues
- the software independent "no signal" problem is due to driver sleep/resume issues

That's exactly what I intended to try too.
The 1,5 TB drive is a pure data drive ; my OS is on SSD, applications are on a separate 300GB HDD. But a RAM drive can't be beaten for timeshifting. If the HDD is a problem, then I have to see how I will go about recording (which could prove difficult on a RAM drive.... )

Great minds think alike!
My comments were based on the assumption that you only had a 1.5TB drive (as listed in your system specs).
What drive/s do you use for timeshifting and recording?
Is the 300GB drive a 7200rpm drive?

A RAM drive really shouldn't be necessary for timeshifting/recording. In my opinion it is only useful when you have a slow HDD, are doing HDD troubleshooting, or you have lots of channels being watched at once (ie. 7200rpm HDD IO requirements exceeded). It would be a useful experiment in this case to determine whether an HDD is the cause of the problem, but I believe you'll have to record to a standard drive so it isn't really a long term solution...

Do you mean that you also run devcon on wakeup ? You do it the way I described, via a scheduled task, or is there another way ?

Another thing : the delayed start for the TV service could be annoying, because it takes a while after wakeup before the service kicks is. In a WOL situation, this could cause the client to complain, or the rest of the family for that matter...
On the other hand, if I have to run devcon on wakeup, I reckon I don't really have a choice but delaying the TV service...

I don't use devcon. I stick with XP, or I run 4095MB of RAM (disable the 1 extra MB). When my tuners disappear they can only be brought back by restarting the computer. Attempting to re-detect devices in device manager or with devcon doesn't help. If I were in your position, I would use a scheduled task that uses devcon to restart the tuner driver if necessary, then starts TV Server. In other words, I wouldn't have a delay on the TV Server startup - I would start TV Server manually with the scheduled task which would run on resume from sleep/hibernate...

 

[Phaedra]

The 1,5 TB drive is a WD15EARS drive. I'm not sure, but as far as I can find info, it's a "variable speed" drive, meaning rpm is between 5400 and 7200.
The RAM drive experiment wasn't really a success, probably because I can't make it large enough (1 GB). I had to limit it to 512 MB, and that caused some problems : stuttering was worse than ever. In the log I could find tswriter getting into trouble regularly, probably from the drive being too small...
When I switched back to my 1,5 TB drive for timeshifting, everything was back to normal.
I still get channel freezing after more than an hour, without anything special in the logs, but as I'm typing this, I see BBC HD streaming getting strange artefacts, and at the same time I hear my HDD getting into some serious action.
I think it would be best if I got myself a separate and dedicated HDD for timeshifting and recording ?
I saw a WD 500 GB drive in the shop, 7200 rpm; SATA-600 6 Gb/s.

 

[mm1352000]

The 1,5 TB drive is a WD15EARS drive. I'm not sure, but as far as I can find info, it's a "variable speed" drive, meaning rpm is between 5400 and 7200.

Yes, it is variable speed; some people say closer to 5400rpm. It is also an "advanced format" drive (4kB per sector). I hope you formatted it with Windows 7, otherwise it will be performing badly. Using it is a timeshift/recording drive is not ideal...

The RAM drive experiment wasn't really a success, probably because I can't make it large enough (1 GB). I had to limit it to 512 MB, and that caused some problems : stuttering was worse than ever. In the log I could find tswriter getting into trouble regularly, probably from the drive being too small...

I assume you changed your timeshift file settings in TV Server configuration to reduce the number of files or size of files used?

I think it would be best if I got myself a separate and dedicated HDD for timeshifting and recording ?
I saw a WD 500 GB drive in the shop, 7200 rpm; SATA-600 6 Gb/s.

Yes, anything 7200rpm should be good. You didn't mention how fast the 300GB drive is though...

 

[Phaedra]

The RAM drive experiment wasn't really a success, probably because I can't make it large enough (1 GB). I had to limit it to 512 MB, and that caused some problems : stuttering was worse than ever. In the log I could find tswriter getting into trouble regularly, probably from the drive being too small...

I assume you changed your timeshift file settings in TV Server configuration to reduce the number of files or size of files used?

Yes, I did change those, but I didn't quite respect the minimum size that was stated there, as I assumed that I was only using timeshifting on 1 channel, while the minimum free space required calculation is based on 3 files...
I guess that this caused the write errors I got while timeshifting.
Doesn't really matter, since I figured out that a RAM drive isn't a viable option for real timeshifting, where the buffer files can get rather big....

I think it would be best if I got myself a separate and dedicated HDD for timeshifting and recording ?
I saw a WD 500 GB drive in the shop, 7200 rpm; SATA-600 6 Gb/s.

Yes, anything 7200rpm should be good. You didn't mention how fast the 300GB drive is though...

Right. It is a Maxtor 7200 rpm drive.
One things boggles me, however.
When I look in resource monitor, I see sustained I/O at 700 KB/sec while doing HD streaming.
My motherboard uses SATA-300 channels, 3 Gbits/sec, being roughly 384 KB/sec. Where did my math go wrong here ?

I might take your hint and try to use my Maxtor drive for timeshifting tests.
But in the end I will be buying a new drive for my definitive TV server, which will clearly be having at least a SATA-600 interface.
I wonder if an SSD is better in this case, but from what I've read it has a lifecycle expressed in number of write cycles per cell...wouldn't this timeshifting high I/O wear this thing out fast ?

 

[Phaedra]

When I look in resource monitor, I see sustained I/O at 700 KB/sec while doing HD streaming.
My motherboard uses SATA-300 channels, 3 Gbits/sec, being roughly 384 KB/sec. Where did my math go wrong here ?

I nominate myself for the "duuh award" :
3Gb/s is 384MB/s

 

[mm1352000]

There is no way that a standard HDD would reach the limits of the SATA 3Gb/s interface. It is more likely to be a problem with incorrect formatting, fragmented drive, other applications using the drive (eg. virus scanner) in combination with the IO requirements from MediaPortal. I'd recommend you try the Maxtor drive, even if only to verify that using a 7200rpm drive solves the problem...