Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> Building home entertainment systems in linux -> Ideal HDTV HTPC?
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Ideal HDTV HTPC?
PostPosted: Fri Jan 20, 2006 12:23 am Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




Currently I have an Athlon 1800+ with 512MB of RAM and a FX5200 video card. This does alright as long as I use XvMC to decode the video, but when I'm recording to an external USB drive, it will occasionally pixelate (not often, but I think when it starts to blink the activity light a lot is the spots where it pixelates) and I'm wondering if my computer isn't fast enough to write even just the audio and video streams since I pick that out of the whole QAM stream. Sometimes I do know it is the station, but I would like to eliminate my computer as the suspect. I think definitely when I try to watch the stream as it's writing that my computer is too slow because it will start blocking up a while after I start watching it as well, so I've decide to let it just record now and watch later.

So what (reasonably priced) components should I use to build a computer that will have no problems? Should I go Pentium 4 or Pentium D or Athlon 64? I hear at least 3GHz is necessary for smooth playback without any hardware acceleration. I'm planning on going at least 1 GB of RAM, is 2 GB necessary or just 1 will do? I think my hard drive is likely fast enough since it's a Western Digital 120GB 7200RPM with 8MB of cache.
View user's profile Send private message
PostPosted: Fri Jan 20, 2006 4:01 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Does it pixelate or drop frames? Do you get buffer overrun messages in /var/log/messages?

I've found that adjusting bdflush to not write stuff out in a short burst helped a lot. Usually bdflush is tuned to collect dirty buffers for several seconds and schedule them to be written to disk in one monster burst. This increases throughput but it kills the responsiveness of the system when those writes are happening.

I adjusted bdflush to spread the writes out more evenly over time. So now when I'm recording two shows instead of hearing "ziip...... ziip....... ziip......." I hear something more like "clickaclickclikckatyclick...."
View user's profile Send private message
PostPosted: Fri Jan 20, 2006 6:29 pm Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




Scott Larson wrote:
Does it pixelate or drop frames? Do you get buffer overrun messages in /var/log/messages?

I've found that adjusting bdflush to not write stuff out in a short burst helped a lot. Usually bdflush is tuned to collect dirty buffers for several seconds and schedule them to be written to disk in one monster burst. This increases throughput but it kills the responsiveness of the system when those writes are happening.

I adjusted bdflush to spread the writes out more evenly over time. So now when I'm recording two shows instead of hearing "ziip...... ziip....... ziip......." I hear something more like "clickaclickclikckatyclick...."

It pixelates. Although it varies. Sometimes I'll get a perfect recording, other times not.
View user's profile Send private message
PostPosted: Sat Jan 21, 2006 9:08 am Reply with quote
maestro
 
Joined: 10 Jul 2004
Posts: 18




kmj0577 wrote:
Scott Larson wrote:
Does it pixelate or drop frames? Do you get buffer overrun messages in /var/log/messages?

I've found that adjusting bdflush to not write stuff out in a short burst helped a lot. Usually bdflush is tuned to collect dirty buffers for several seconds and schedule them to be written to disk in one monster burst. This increases throughput but it kills the responsiveness of the system when those writes are happening.

I adjusted bdflush to spread the writes out more evenly over time. So now when I'm recording two shows instead of hearing "ziip...... ziip....... ziip......." I hear something more like "clickaclickclikckatyclick...."

It pixelates. Although it varies. Sometimes I'll get a perfect recording, other times not.


I had a similar problem when playing back during recording, except playing back HD while HD was recording caused the recorded program to be unwatchable (lots of "buffer overrun" errors). After I switched my filesystem from ext3 to XFS, the problem vanished completely. This is on a SP8000E (VIA C3), so it was probably more susceptible to hitting this tipping point.
View user's profile Send private message
PostPosted: Sat Jan 21, 2006 6:39 pm Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




I'm doing a stress test with a HD movie right now. I'm letting it sit and record for 3 hours and I'll see how it turns out after.

I do have my hard drive formatted as XFS as well.
View user's profile Send private message
PostPosted: Sat Jan 21, 2006 8:39 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




kmj0577 wrote:
It pixelates. Although it varies. Sometimes I'll get a perfect recording, other times not.

Check /var/log/messages to see if you're getting buffer overruns. If you aren't something else is causing your pixelixation.
View user's profile Send private message
PostPosted: Sat Jan 21, 2006 8:43 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




maestro wrote:
After I switched my filesystem from ext3 to XFS, the problem vanished completely. This is on a SP8000E (VIA C3), so it was probably more susceptible to hitting this tipping point.

Does XFS do journalling? The journalling overhead on ext3 can be pretty severe (we've set our customers' systems to only journal file systems that we have to journal) but fscking a 400GB filesystem can take a long time.
View user's profile Send private message
PostPosted: Sat Jan 21, 2006 11:01 pm Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




Yeah, XFS does journaling, but it's supposed to have a low impact on transactions if you believe the SGI page.

I haven't had a chance to look at my 3 hour capture of Enemy of the State that was on ABC tonight, but doesn't look like any buffer overruns in my log.

This is the only activity I can find by grepping cx88:
Quote:
Jan 21 19:01:02 Tux cx88[0]/2: queue is empty - first active
Jan 21 19:01:02 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 19:01:02 Tux cx88[0]/2: setting the interrupt mask
Jan 21 19:01:02 Tux cx88[0]/2: [d6d34a80/0] cx8802_buf_queue - first active
Jan 21 22:00:52 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 22:00:52 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:31:33 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:31:33 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:31:33 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:31:33 Tux cx88[0]/2: [c2e3baa0/0] cx8802_buf_queue - first active
Jan 21 23:32:06 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:32:06 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:32:34 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:32:34 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:32:34 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:32:34 Tux cx88[0]/2: [d6d34a80/0] cx8802_buf_queue - first active
Jan 21 23:34:26 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:34:26 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:45:01 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:45:01 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:45:01 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:45:01 Tux cx88[0]/2: [d6d34b40/0] cx8802_buf_queue - first active
Jan 21 23:45:49 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:45:49 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:45:54 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:45:54 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:45:54 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:45:54 Tux cx88[0]/2: [d6d34a80/0] cx8802_buf_queue - first active
Jan 21 23:46:56 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:46:56 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:47:08 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:47:08 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:47:08 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:47:08 Tux cx88[0]/2: [d6d34b40/0] cx8802_buf_queue - first active
Jan 21 23:47:11 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:47:11 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:47:12 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:47:12 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:47:12 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:47:12 Tux cx88[0]/2: [d6d34a80/0] cx8802_buf_queue - first active
Jan 21 23:47:15 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:47:15 Tux cx88[0]/2: cx8802_restart_queue: queue is empty
Jan 21 23:47:16 Tux cx88[0]/2: queue is empty - first active
Jan 21 23:47:16 Tux cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Jan 21 23:47:16 Tux cx88[0]/2: setting the interrupt mask
Jan 21 23:47:16 Tux cx88[0]/2: [d6d34b40/0] cx8802_buf_queue - first active
Jan 21 23:47:26 Tux cx88[0]/2: cx8802_restart_queue
Jan 21 23:47:26 Tux cx88[0]/2: cx8802_restart_queue: queue is empty


Actually I don't spot any anywhere. Would buffer overruns be the only thing that would cause pixelation on my end? Perhaps it is just my stations.

Here's what MPlayer spits out when it pixelates anywhere:
Quote:
[mpegvideo_xvmc @ 0x8597108]concealing 1009 DC, 1009 AC, 1009 MV errors
[mpegvideo_xvmc @ 0x8597108]concealing 1009 DC, 1009 AC, 1009 MV errors
[mpegvideo_xvmc @ 0x8597108]skiped MB in I frame at 116 30 ??,?% 0 0
[mpegvideo_xvmc @ 0x8597108]skiped MB in I frame at 102 32
[mpegvideo_xvmc @ 0x8597108]Warning MVs not available
[mpegvideo_xvmc @ 0x8597108]concealing 181 DC, 181 AC, 181 MV errors


I get these all the time on TNTHD (then again I don't really plan to watch much TNTHD since there's only about 5 true HD programs and the rest, even the movies, are just stretch 3:2 (720x480) content, although the extra upscaling and bitrate do make it look good, it would still be nice to have it in OAR and uncut since they do edit some stuff for time mostly) and rarely on other stations really (unless something really goes wrong). I'm still trying to figure out which end the kinks are on. And since my /var/log/messages shows nothing revealing except for messages like the ones above, guess it's my stations who need to work out the kinks Confused

Edit: Adding a really large buffer (81920) helps with TNT some.
View user's profile Send private message
PostPosted: Mon Jan 23, 2006 11:09 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




So watching live doesn't give you any errors with mplayer (just recapping to make sure this isn't a reception problem)? There is a bug in recent versions of mplayer that make it have trouble parsing ATSC when reading directly from the device (I only hit this with my ABC station) but not from disk. This of course is the opposite of your problem but no one has figured out what the problem is yet (I'm working on other mplayer problems).

If the files you're saving are defective then data has to be getting lost somewhere. If it's because your system is slow, it has to be the result of buffer overruns. That's the only link in the chain I can think of where the system can chose to throw data away.

BTW, TNT-HD will often broadcast more hours of true HD per day than OTA networks. ABC, CBS, FOX, and NBC stations only broadcast 15%-20% of their programming in HD. TNT-HD's stretching is really annoying. Their upconversions would look fantastic if they weren't stretched.
View user's profile Send private message
PostPosted: Mon Jan 23, 2006 2:28 pm Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




Scott Larson wrote:
So watching live doesn't give you any errors with mplayer (just recapping to make sure this isn't a reception problem)? There is a bug in recent versions of mplayer that make it have trouble parsing ATSC when reading directly from the device (I only hit this with my ABC station) but not from disk. This of course is the opposite of your problem but no one has figured out what the problem is yet (I'm working on other mplayer problems).

If the files you're saving are defective then data has to be getting lost somewhere. If it's because your system is slow, it has to be the result of buffer overruns. That's the only link in the chain I can think of where the system can chose to throw data away.

BTW, TNT-HD will often broadcast more hours of true HD per day than OTA networks. ABC, CBS, FOX, and NBC stations only broadcast 15%-20% of their programming in HD. TNT-HD's stretching is really annoying. Their upconversions would look fantastic if they weren't stretched.

Well, I don't read directly from the device with mplayer though. I use dvbstream to pick out the audio and video PIDs and send them into MPlayer using a pipe. I don't have any trouble watching it live really.

I suppose it is the networks then if no buffer overrun is in my logs.
View user's profile Send private message
PostPosted: Tue Jan 24, 2006 11:31 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Not if you can watch them live with no problems.
View user's profile Send private message
Ideal HDTV HTPC?
  pcHDTV Forum Index -> Building home entertainment systems in linux
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 1 of 1  

  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin