Comment 8 for bug 160447

Hi Daniel,

That's interesting. I was looking through the miro source the other
day and I saw some mention of a hack that they had done to get
lib-xine to select a better video driver. I didn't take much notice
but maybe this is exactly the issue that they are talking about.

So, we've got your video problem sorted out, right? Now just the
audio. Why wouldn't ALSA like your audio setup? Especially now that
we know that it worked for Dale. I've got nothing! Grasping at
straws here ... are you sure that you got the right audio PID? I ask
because xine and mplayer ignore this and work it out automatically by
sniffing the stream. Me TV does not ignore so it's very important
that you got it right.

Oh dear, the old "hanging with the pointing finger trick", gets me
every time. This is a current issue with the current version of Me
TV. We probably shouldn't call it stable, really. I've spent the
last 2 months on this issue and it seems be improved but not gone
completely. I don't know what's causing it and on-top of that it's a
heisenbug (see http://zebrawords.com/index.php?q=heisenbug&database=*&strategy=exact&type=).
 I'm currently taking suggestions from anyone so if you've got any
coding experience then please feel free to jump in and have a look.

You'll also find that Alt-F4 will get you out of trouble.

Thanks,

Michael

On 07/11/2007, Daniel Newman <email address hidden> wrote:
>
> >> It might be that lib-xine is not picking the best driver for you.
> >> Please run `xine --help` to see a list of available video/audio drivers
> >> (-V,-A options) and try playing around with those in the ~/.me-tv/me-
> >> tv.config (hope you know XML). Let's see where that takes us.
> >>
> Some interesting results here. The only video drivers that worked at
> all were xv, opengl, and xshm.
>
> xv worked for whichever channel me-tv was started in (either HD or SD),
> but changing to other channels while running generated the problem with
> interlacing and apparent wrong scan lengths. Maybe there is some
> dimension which is being initialised on startup but not re-initialised
> on channel change? xv used about 13% of 1 cpu on SD and 4. Sometimes
> channel changes crashed the xserver.
>
> opengl worked well for all channels, with usage of 1 cpu at about 15% on
> SD and 50% on HD.
>
> xshm worked well for all channels, with usage of 1 cpu at 23% on SD and
> 75% on HD.
>
> I'm guessing that the original "auto" setting was defaulting to xv, but
> it looks like opengl would be the best choice.
>
>
> The only audio driver I had installed was alsa. It provided normal
> sound on all SD channels and on SBS HD, but no sound on any of the other
> HD channels.
>
> On a different issue, I've noticed that the EPG doesn't always seem to
> respond properly to mouse inputs. Sometimes after a single click on a
> channel or program the cursor will remain as a pointing hand, the
> channel change will not take place (no message to terminal) and the
> focus will not leave the me-tv window. The only way out is Alt-F9 to
> minimise me-tv, then kill it from the terminal.
>
> Hope all this helps, since me-tv seems a very good application if these
> minor bugs can be sorted out.
>
> Thanks,
> Dan
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a bug assignee.
>