I've been getting pauses (or stutters?) every two seconds in both live tv and recorded shows, but only on a low end (K63-400 mhz) box. My laptop (1.8 mhz celeron) can play either stream fine, so I don't think it's a server or recording issue.

However, when I turn on the automatic transcode after recording option, the recorded shows don't gap at all... Even if we are watching the show while it's being recorded, it runs fine.

What additional information would you (or anyone else) like? Details are helpful. I provided what I thought was enough... feel free to enlighten me.

The low end box plays the recorded shows fine. To me, that indicates that something within Myth is treating those recordings differently. Since I'm watching them live while they are being recorded, and the dialog indicate that the transcoding is done after the recording is completed, it doesn't seem to be related to stream content post-transcode... but maybe it transcodes on the fly? I'm wondering if anyone knows if Myth is treating these recordings differently, and if so, can I get the live tv to be handled the same way.

TV tuner card info would be helpful. When you watch live TV, you are encoding and decoding, this take more processing power than when you watch a recorded show. MythTV doesn't treat the files differently.

Front end box is a K6-3 400mhz w/256 megs of memory. The video card is an Nvidia GeForce 4 480MX (a newer version of the 440). I think it's go 64 meg of memory, but it may have 128. The system is also Kubuntu but the same symptoms occur with a like KnoppMyth CD. The box stays at 80 to 90% cpu during playback.

Network: Server plugs into a 100 mb switch, then goes through a 100 mb router (in the switch ports), then to a 10 mb switch. Since it's 3 hops, I mention it, but the laptop I mentioned earlier plays the video fine on the network connection.

This box seemed to work fine w/0.16 but I only did "proof of concept" with it, but now we've replaced the Tivo, so we're looking at it much more.

If I turn the "automatically transcode" option off, everything being played (live or recorded) gaps. When Transcode automatically is on, the recorded shows don't gap.

Is it possible that the server is transcoding on the fly and the client box can more easily handle the stream (as it's half the size)? I use ~2 gigs an hour raw, then it transcodes (to MPEG4) to just under 1 gig an hour.

The problem with low spec machines that otherwise work for real-time applications like this usually ends up being missed deadlines. Rather like climbing rope it's not the average load that's an issue but rather the momentary peak load.

You can try turning up the buffering via the setup screens and aggressively "nice-ing" background processes like transcoding. However you may still find that the CPU doesn't have enough headroom to handle some transitory peak loads without maxing out. Basically, under heavy load it can't finish certain urgent tasks fast enough to get back to feeding smooth video.

Reading the current mythtv docs on the mythtv.org website, there should be no difference. Assuming it is up to date with the real behavior of 0.17, transcoding isn't supposed to happen until after the recording is finished.

I wonder if something very strange is happening such as: you get better live video on the slow frontend if the backend is currently performing a low priority transcode on a recently recorded program? That seems sorta silly though, but I've seen stranger things happen.

One more thing: have you set up the mythfrontend suid root on the slow machine? According to the output of mythfrontend, that can help sometimes, and it sounds like the hardware you're using is perhaps only a tad underpowered, so the suid thing might push you back into the land of acceptable performance.

I also wondered if the extra load on the server machine was actually slowing something down enough for the lowly front-end box to handle it. Still seems odd though, but like you said, stranger things have happened.

And yes, I'm running myth w/sudo mythfronend.

What sorts of speeds are other people using for dedicated front-end boxes? I've got an Athlon 550 upstairs but it's use as a server box. I could swap them but it would mean a lot of work, especially if it's still not "fast enough".

It may seem counter-intuitive but a FE often needs more horsepower than a BE. This is especially true with a PVR card (Yes, I know you don't have one). Playback is more demanding about the amount of headroom it has because the destination device (the protoplasmic one wearing your skin) is quite sensitive to buffering delays, so you really can't miss your realtime deadlines.

When you're recording, if a momentary load spike happens it may not be an issue if you got some spare buffer space where the data can sit for a couple seconds. It's in a buffer, and it can be processed and dumped to the disk as soon as the CPU gets some spare cycles. If it goes in chunks nobody really cares just so long as things don't backup to the point that the buffers overflow.

Now, what I was trying to explain to you earlier was very closely related to this:

- If the data to display the next frame isn't ready the display will "glitch" and not be smooth. This is the streaming part.

- Meeting the deadlines means getting enough CPU cycles early enough in each time window (the period between displaying one frame and the next) to get that data ready and to the video card before the next frame has to be displayed.

- The less free CPU you have and the slower the CPU clock is, the earlier in the window you absolutely positively have to get you cycles (with no interuptions) if you're going to make the deadline.

- If your data arrives late for any reason (maybe because the back end is busy or the CPU didn't have enough free cycles to handle the network traffic) You can't start your processing for the current window.

- If something else (another task, netowrk traffic, ...) is "distracting" the CPU during your window the deadline may not be met.

So, there's always the chance that 0.17 was doing autotranscode on live TV too. However, it's not listed as a feature in any documenation that I've read.

Course I could be reading too much into that: those changes might only apply to boards without hardware decoders (not the PVR-xxx series) that require mythtv to perform an encoding step before writing video to disk.

The transcoding does appear to be running "realtime". My CPU on the client box can playback the MPG encoded streams smoothly, but gaps with RTJPEG or plain live TV. The gaps and quality of the stream make it very obvious which one I'm seeing. The server box uses about 60% of the CPU when recording w/o transcoding, but pegs the CPU when automatically transcode is checked.

I tried wiping the frontend box and installing KnoppMyth (instead of the Kubuntu I'd been using) to see if the performance would be better. I found it difficult to use. It was interesting that the install made no allowance for a front-end client. It assumes everything is running on the same box... not complaining mind you (it's a great distro!), but I had to dig the info out of the fourms on how to disable everything cleanly.

I also had trouble getting the native Nvidia drivers installed on the KnoppMyth version. I guess it's what version you know... anyway, X was ~very~ slow under KnoppMyth, so I probably wouldn't have kept it anyway, but the video gapped worse under KnoppMyth than it did under Kubuntu...

sooo....

I used the KnoppMyth live CD to see how my Athlon 550 mhz did at video playback, and it looks to be fine. I am currently moving Tomcat, Apache, CVS, etc and so forth off of the Athlon and I'll setup it all back up on the 400mhz box, making it the server. Then the Athlon will get to be the Myth box.

More than you wanted to know?

I found a few posts in the forums that indicate you can run Myth w/slower hardware than my 400 mhz, but they seem to be watch recorded shows more than live TV.

Anyway, thanks for the helpful posts all! Despite all the noise, I think I've finally figured out what the streams were doing. If it we were only using the box to watch recorded content and we recorded it as MPEG, 400 mhz would have been fine, but it couldn't handle live TV.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum