[mythtv] [mythtv-commits] Ticket #4606: Broken progress bar in DVB-Radio playback plus stuttering

Stuart Auchterlonie stuarta at squashedfrog.net
Thu Feb 21 20:31:48 UTC 2008


Mark Buechler wrote:
> Hi.
> 
> On Wed, Feb 20, 2008 at 10:08 PM, MythTV <mythtv at cvs.mythtv.org 
> <mailto:mythtv at cvs.mythtv.org>> wrote:
> 
>     #4606: Broken progress bar in DVB-Radio playback plus stuttering
>     -------------------------------------------+--------------------------------
>      Reporter:  Robin Gilks <g8ecj at gilks.org <mailto:g8ecj at gilks.org>>
>      |        Owner:  ijr
>         Type:  defect                         |       Status:  new
>      Priority:  blocker                        |    Milestone:  0.21
>     Component:  mythtv                         |      Version:  head
>      Severity:  medium                         |   Resolution:
>      Mlocked:  0                              |
>     -------------------------------------------+--------------------------------
> 
>     Comment(by latepaul at gmail.com <mailto:latepaul at gmail.com>):
> 
>      I'm hitting this problem too. What I've noticed is that if you
>     pause the
>      playback and then unpause it starts again and 'corrects' the
>     stuttering.
> 
>      Also when I first hit this problem I experienced it as the whole
>     machine
>      hanging. I discovered that it wasn't actually hanging but that the
>      mythfrontend was taking all the CPU. It would eventually respond to
>     e.g. a
>      keypress, but it was taking forever and practically speaking I had to
>      reboot.
> 
>      I had real-time priority set up using /etc/security/limit.conf. When I
>      disabled this I got the problem as described here - stuttering. I
>     also see
>      the progress bar as '01 of 01'
> 
>      When listening to DVB Radio view LiveTV I don't get this problem. I can
>      play back the underlying recording file with mplayer without
>     stuttering.
> 
>      Let me know if you want me to upload any logs etc.
> 
> 
> I believe the stuttering is from the stream size difference between 
> pre-multirec and trunk. The old way was to create dummy video and record 
> it along with the audio. Now the dummy video is being created on-demand 
> by the frontend - thus reducing the size of the stream. I believe the 
> read size is too large for such a small stream. However, adjusting it 
> will affect video streams. This may be where specialized storage groups 
> comes in handy - one for DVB audio only.
>  

No, surely we know when we are processing an audio channel and should
compensate the read buffer requirements to match.

Specialized storage groups in this situation is pure and utter butchery.


Stuart


More information about the mythtv-dev mailing list