doesn't really matter that's more than enough for mythtv. unless you are trying to cram like 4 or 5 hdtv cards in there.

_________________
Have a question search the forum and have a look at the KnoppMythWiki.

Xsecrets

Just wondering than how come iowait is so high when I'm running commercial_cut. All it is doing technically is copying a very large file of few gigabytes.

I've one HDTV card and will add atleast 1 more.
Thanks

Mudit

I don't know that much about how the commercial_cut works, but I do know that io is about the biggest bottlneck in a system anymore, and unfortunately can't be preempted. I imagine it will be quite some time before a problem like that will be tracked down and corrected. for now you may just have to schedule the comm cut at off times.

_________________
Have a question search the forum and have a look at the KnoppMythWiki.

Xsecrets

It only takes a few minutes to cut a recording anyway.

I run comcut in batch on multiple files and my each file is somewhere from 3gb (1/2 hr HD programming) to 12 GB ( 2 hour movie). So, I try to run comcut later at night before I auto shutdown my computer via scripts.

But its a great program and should be included in the mythtv plugin/suite !

Thanks
Mudit

That's correct, Mudit. Linux doesn't schedule IO. Any program that is mainly reading and writing data from the disk will have high IOwait.

What the nice will do is, if mythbackend is trying to record a program at the same time, it's IO requests will usually sent and received first. It is only if it has spare time that commercial_cut will be able to request data. It isn't guaranteed, but as long as you don't need more IO bandwidth than is available, nice will usually prioritise the disk access by prioritising the tasks that are filling and emptying the buffers.

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

Nigel,

Even with comcut niced, when I'm doing a recording, I get DVB buffer error messages in my backend. So, I just have to make sure not to overlap recording and comcut.

Thanks

Mudit

perhaps we could add a command line feature that limits the i/o rate of commercial cut, and implement it using delays in the code. This would slow it down but it may minimise its impact on other applications.

Greg,

I just added a usleep(1000) after the fwrite calls. That makes huge difference in system response. Before the change, when I try to access the mythweb, the browser will wait for sometime and then finally mythweb/php will return some sort of error message ((for eg mythbackend not running etc).

Now, with usleep(1000) (which translates to 1ms wait), the mythweb response is instantenous. No more mythweb hang ups.

But I'm still getting IOBOUND blocking messages in the backend when I try to record and run commcut (niced at 19) at the same time, even with usleep(1000). Will increase that to usleep(5000) and then see. It'll make the program probably crawl.

2005-06-29 12:37:57.662 IOBOUND - blocking in ThreadedFileWriter::Write()
2005-06-29 12:38:02.060 IOBOUND - blocking in ThreadedFileWriter::Write()
2005-06-29 12:38:02.450 IOBOUND - blocking in ThreadedFileWriter::Write()
2005-06-29 12:38:07.003 IOBOUND - blocking in ThreadedFileWriter::Write()
2005-06-29 12:38:21.914 IOBOUND - blocking in ThreadedFileWriter::Write()


Thanks
Mudit

I think my IOBound problems may be due to 2.6.11 kernel and/or smaller buffer size in the libmythtv/RingBuffer.cpp. I searched the myth-users mailing list and looks like the buffer is only 2MB. It may be okay for non-hd stuff but for hdtv its too small because the frame rate is 19.2Mbps.

I may try to upgrade my kernel in the weekend, and repeat the same experiment.

Thanks

Mudit
p.s.: edited: kernel is 2.6.11.7 (knoppix myth R5A15.1 CD)

Upgraded to 2.6.12.1. But still getting IOBound error messages in the backend when commercial cut is running with nice 20 and usleep(1000).

I think its the mythtv code which needs tweaking.

Thanks
Mudit

I did change the buffer size from 2MB in RingBuffer.cpp to 8MB. Now I dont get that IOBound message every other second. I do see it once the file is being opened or closed. So not as bad as before.

I'm no kernel hacker, but lowering the priority of a process that has non-preemptable IO may lead to priority inversion (look that up as a computer science topic if it is a new term, or I can explain it, but it's off-topic here), therefore guaranteeing a worse outcome. Hmmm. If so, this is a battle you can't win: if you raise priority, you have more preemptable IO; if you lower priority, you have less IO but you must wait longer for it in any case. Just my 2c.

On the other hand, here is a n00b question that is keeping me awake at night: how are commercials flagged? I.e., how is the information gathered in the first place about what is a commercial and what is the real program? Mind, not how it is recorded or used, but rather how does a MythTv recording distinguish between a scene of Star Wars and a jingle for a toothpaste?

Another question--I'm new to all these video formats. What format is a pc3000 going to save as, and will commercial_cut work for it also?

Alas, I'm about to build my first MythTV and get my hands dirty eventually . HW should be on the way, wish me luck.

Cheers,

Alberto.

There is a big discussion going on myth-dev users list about commercial flagging. You may want to check it out. http://www.gossamer-threads.com/lists/mythtv/dev/138967

All digital cards records in mpeg2 format. Some analog cards (such as pvr x50) also convert analog to mpeg2. All the recordings are saved in RTjpeg(sp?) or similar format for other analog cards. Raw video cannot be stored unless you have terrabytes of hard drive.

I've HD3000 card and using commercial cut successfully. Had to make some changes to make it -nice after couple of fwrites , passed a flag -d to always delete the recording and -s option also takes the mythcommflag --starttime based format (code based on 0.5).

Thanks for pulling this together!

I have a PVR-250 and record an NTSC signal. When I ran my first test, the cutpoints were incorrect. I believe that the problem is the x50 multipler of 12. I changed the value to 15 and that does the trick for my recordings.

My thinking is that this is due to the NTSC frame rate of 30 (29.97?), vs PAL's 25. Seem reasonable? Perhaps there's a way to detect this from the MPEG file?

All I did in my copy was pull the multiplier out (3 places) into a global and then changed that value to 15. If auto-detect isn't possible, then I suppose a command-line or compile-time flag would be fine to set it.

Thoughts?

thanks again!