problems with Australian (Sydney) HD channels

Bug #160447 reported by Daniel Newman
14
Affects Status Importance Assigned to Milestone
Me TV
Fix Released
Medium
Unassigned
1.0
Fix Released
Medium
Unassigned

Bug Description

I'm using version 0.4.2 from the deb package. I built the channels.conf for my area (Sydney, Australia) in accordance with the web site instructions, including changing the HD audio from 0 to the correct number. For example, the ABC HDTV entry is:

ABCHDTV:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2314:2315:544

On this and other HD channels, me-tv produces no sound. Also, the HD video does not appear to be displayed properly. It seems to be interlaced and offset, as if the horizontal line lengths do not match the scan length. This can be avoided if the config file is edited to start in the HD channel, but channel changes within the program to another HD channel will cause the video problem to occur again.

The other, SD channels all work fine.

I've also tested the same channels.conf using "totem dvb://ABCHDTV", which displays normally and has the audio working.

Any other suggestions?

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Sounds very interesting. I can honestly say that I've never tried the HD channels in Me TV because I've always thought that they don't add anything except CPU time. Your bug is the first that I've heard of the channels being an issue.

Let's start the troubleshooting process. How did you know to put 2315 in the audio part?

Thanks,

Michael

Changed in me-tv:
assignee: nobody → michael-lamothe
importance: Undecided → Medium
milestone: none → station-4
status: New → Confirmed
Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Well it appears that I've missed something. While examining the HD channels, it appears that they send an AC3 stream, not an AUDIO stream. I'll have to look further into this. I think that it might just be a case of selecting a different audio driver. As for the video corruption, I'll have a look tomorrow.

Revision history for this message
Daniel Newman (dmnewman) wrote : Re: [Bug 160447] Re: problems with Australian (Sydney) HD channels

on 07/11/07 00:11 Michael Lamothe said the following:
> Sounds very interesting. I can honestly say that I've never tried the
> HD channels in Me TV because I've always thought that they don't add
> anything except CPU time. Your bug is the first that I've heard of the
> channels being an issue.
>
> Let's start the troubleshooting process. How did you know to put 2315
> in the audio part?
>
> Thanks,
>
> Michael
>
> ** Changed in: me-tv
> Importance: Undecided => Medium
> Assignee: (unassigned) => Michael Lamothe (michael-lamothe)
> Status: New => Confirmed
> Target: None => station-4
>
>
From the Linux TV wiki, see

http://www.linuxtv.org/wiki/index.php/Scan

in the section "A word about dvbscan and audio streams" it describes how
to handle AC3 audio. I just followed those instructions.

thanks,
Dan

Revision history for this message
Dale (quail-linux) wrote :

This is very interesting as the on HD TV I get here in Adelaide is SBS HD no problem it comes in clear as a bell with Me TV. I have had a look at the link that Daniel has supplied and see if I can get the other channels to work. I got the ABC HDTV channel to work and tested it under mplayer, but that gives me a warning that my 1.6GHz machine is not fast enough.

Attached is an output of mplayer if it any help

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Thanks for that Dale. Who's the other smarty-pants from Adelaide? That's a neat trick. I've been running "xine --verbose dvb://ABC HD" to get the other PIDs.

Daniel, just a few questions?

1. Have you installed totem-xine or totem-gstreamer (default) installed?
2. Can you please test the channel with xine and see if you get the same results?
3. Can you tell us a little bit about your machine, speed, video card, video driver, xserver?

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.

Thanks,

Michael

Revision history for this message
Daniel Newman (dmnewman) wrote :

on 07/11/07 12:21 Michael Lamothe said the following:
> Thanks for that Dale. Who's the other smarty-pants from Adelaide?
> That's a neat trick. I've been running "xine --verbose dvb://ABC HD" to
> get the other PIDs.
>
> Daniel, just a few questions?
>
> 1. Have you installed totem-xine or totem-gstreamer (default) installed?
>
totem-xine
> 2. Can you please test the channel with xine and see if you get the same results?
>
All the HD channels work fine under totem-xine, both video and audio,
using the same channels.conf used for me-tv.
> 3. Can you tell us a little bit about your machine, speed, video card, video driver, xserver?
>
Macbook Pro 15in, Intel Core Duo 2GHz processor, linux 2.6.23.1 kernel
with the current mactel-linux patches, ATI Mobility Radeon X1600 video
card, ATI fglrx video driver version 8.42.3, X.Org xserver, ubuntu
package version 2:1.3.0.0.dfsg-12ubuntu8
> 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.
>
OK, I'll have a play with this and report back.
> Thanks,
>
> Michael
>
>
Thanks,
Dan

Revision history for this message
Daniel Newman (dmnewman) 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

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :
Download full text (3.3 KiB)

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 sor...

Read more...

Revision history for this message
Daniel Newman (dmnewman) wrote :

on 07/11/07 15:52 Michael Lamothe said the following:
> 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.
>
I'm using the same channnels.conf which works under totem, and it seems
that me-tv is using the correct audio PID:

07/11/07 16:28:24 - Request to change channel to 'ABC HDTV'
07/11/07 16:28:24 - Changing channel to 'ABC HDTV'
07/11/07 16:28:24 - --> Stopping EPG thread
07/11/07 16:28:24 - <-- Stopping EPG thread
07/11/07 16:28:24 - Purging remaining EPG events
07/11/07 16:28:24 - EPG events purged
07/11/07 16:28:24 - --> Stopping stream thread
07/11/07 16:28:24 - <-- Stream loop
07/11/07 16:28:24 - <-- Stream thread function
07/11/07 16:28:24 - <-- Stopping stream thread
07/11/07 16:28:24 - Closing xine stream
07/11/07 16:28:24 - Tuning to 'ABC HDTV' ...
07/11/07 16:28:25 - Tuned to 'ABC HDTV'
07/11/07 16:28:25 - --> Opening FIFO for writing
07/11/07 16:28:25 - <-- Opening FIFO for writing
07/11/07 16:28:25 - Stream thread created
07/11/07 16:28:25 - EPG thread created
07/11/07 16:28:25 - --> Stream thread function
07/11/07 16:28:25 - Video thread created
07/11/07 16:28:25 - About to open FIFO
'fifo://home/dmn/.me-tv/video.fifo' ...
07/11/07 16:28:25 - Stream Thread: Set video PID filter to 2314
07/11/07 16:28:25 - Stream Thread: Set audio PID filter to 2315
07/11/07 16:28:25 - --> Stream loop
07/11/07 16:28:25 - Channel changed to 'ABC HDTV'
07/11/07 16:28:25 - About to play from FIFO ...
07/11/07 16:28:25 - Playing from FIFO
AFD changed from -2 to -1

Also, it looks to me like Dale only got the SBS HD audio to work under
me-tv (which works for me also). To get the ABC HD audio to work he
used mplayer (which also works for me).

The problem for me-tv applies to all the HD channels except SBS (ABC, 7,
9, 10).

More suggestions, please?

Dan

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Same problem in Canberra on my setup. Haven't tested whether totem is
any better, had to get off the TV but I can confirm that there are
issues. Looking into the code now.

On 07/11/2007, Daniel Newman <email address hidden> wrote:
> on 07/11/07 15:52 Michael Lamothe said the following:
> > 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.
> >
> I'm using the same channnels.conf which works under totem, and it seems
> that me-tv is using the correct audio PID:
>
> 07/11/07 16:28:24 - Request to change channel to 'ABC HDTV'
> 07/11/07 16:28:24 - Changing channel to 'ABC HDTV'
> 07/11/07 16:28:24 - --> Stopping EPG thread
> 07/11/07 16:28:24 - <-- Stopping EPG thread
> 07/11/07 16:28:24 - Purging remaining EPG events
> 07/11/07 16:28:24 - EPG events purged
> 07/11/07 16:28:24 - --> Stopping stream thread
> 07/11/07 16:28:24 - <-- Stream loop
> 07/11/07 16:28:24 - <-- Stream thread function
> 07/11/07 16:28:24 - <-- Stopping stream thread
> 07/11/07 16:28:24 - Closing xine stream
> 07/11/07 16:28:24 - Tuning to 'ABC HDTV' ...
> 07/11/07 16:28:25 - Tuned to 'ABC HDTV'
> 07/11/07 16:28:25 - --> Opening FIFO for writing
> 07/11/07 16:28:25 - <-- Opening FIFO for writing
> 07/11/07 16:28:25 - Stream thread created
> 07/11/07 16:28:25 - EPG thread created
> 07/11/07 16:28:25 - --> Stream thread function
> 07/11/07 16:28:25 - Video thread created
> 07/11/07 16:28:25 - About to open FIFO
> 'fifo://home/dmn/.me-tv/video.fifo' ...
> 07/11/07 16:28:25 - Stream Thread: Set video PID filter to 2314
> 07/11/07 16:28:25 - Stream Thread: Set audio PID filter to 2315
> 07/11/07 16:28:25 - --> Stream loop
> 07/11/07 16:28:25 - Channel changed to 'ABC HDTV'
> 07/11/07 16:28:25 - About to play from FIFO ...
> 07/11/07 16:28:25 - Playing from FIFO
> AFD changed from -2 to -1
>
> Also, it looks to me like Dale only got the SBS HD audio to work under
> me-tv (which works for me also). To get the ABC HD audio to work he
> used mplayer (which also works for me).
>
> The problem for me-tv applies to all the HD channels except SBS (ABC, 7,
> 9, 10).
>
> More suggestions, please?
>
> Dan
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a bug assignee.
>

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Ok, I think that I've found it by looking through the DVB input plugin of the libxine source. AC3 audio streams need to be set as a DMX_PES_OTHER type filter. I currently set any PID in that field as a DMX_PES_AUDIO filter type. The issue is that there's no way for me to know this without processing the stream first. This is something that I've always avoided because its a bit of work and I never could work out why people were doing it. Now I know.

I can now see why dvb/scan sets this field to 0 because technically both of them could be available (AC3 and standard audio). Basically, this is a flaw in the channels.conf format, not the application.

After we confim that this is the issue, we have a few options:

1. Ignore it for now (The SD stations deliver the same content in Australia and no one else has complianed)
2. Create a stream sniffer that determines the type of audio stream when we start (could take weeks)
3. Hack the line so that there's an extra field on the end for AC3 (Ugly but effective for now)

Option 2 is the best but I'll get your impression on what you think before I start a blueprint for this.

Revision history for this message
Daniel Newman (dmnewman) wrote :

on 07/11/07 20:25 Michael Lamothe said the following:
> Ok, I think that I've found it by looking through the DVB input plugin
> of the libxine source. AC3 audio streams need to be set as a
> DMX_PES_OTHER type filter. I currently set any PID in that field as a
> DMX_PES_AUDIO filter type. The issue is that there's no way for me to
> know this without processing the stream first. This is something that
> I've always avoided because its a bit of work and I never could work out
> why people were doing it. Now I know.
>
> I can now see why dvb/scan sets this field to 0 because technically both
> of them could be available (AC3 and standard audio). Basically, this is
> a flaw in the channels.conf format, not the application.
>
> After we confim that this is the issue, we have a few options:
>
> 1. Ignore it for now (The SD stations deliver the same content in Australia and no one else has complianed)
> 2. Create a stream sniffer that determines the type of audio stream when we start (could take weeks)
> 3. Hack the line so that there's an extra field on the end for AC3 (Ugly but effective for now)
>
> Option 2 is the best but I'll get your impression on what you think
> before I start a blueprint for this.
>
>
It's obviously something that needs doing, but I don't think there is
any hurry. Maybe you should just add option 2 at the end of your list
of things to do. If I decide meanwhile that I really can't live without
HD I can always get the source and do a quick hack specifically for my
local channels.

Thanks for your help,
Dan

Revision history for this message
Dale (quail-linux) wrote :
Download full text (3.8 KiB)

I have worked out the PID audio number for the HD channels using "w_scan" and then copy and pasting the the PID HD audio number over to the channels.conf. Here is a copy of my channels.conf file now.

ABC HDTV:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2314:2315:592
ABC TV Adelaide:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:593
ABC2:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2307:2308:594
ABC TV:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:595
ABC DiG Radio:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:2317:598
ABC DiG Jazz:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:2318:599
7 Digital:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1281:1282:1360
7 Digital 1:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1281:1282:1361
7 Digital 2:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1281:1282:1362
7 Digital 3:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1281:1282:1363
7 HD Digital:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1345:1347:1364
7 Guide:177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1377:1378:1366
NINE Digital:191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1105
NINE HD:191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:651:1112
TEN Digital:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1617
TEN Digital:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1621
TEN Guide:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:660:1623
TEN HD:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:672:1624
TEN Guide:219500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:660:1625
SBS HD:564500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:102:103:832
SBS:564500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE...

Read more...

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Thanks Dale. Daniel, can you confirm if this works for you? I tried using the AC3 PIDs that xine gave me but that didn't work. This could've been for many reasons though.

Thanks,

Michael

Revision history for this message
Daniel Newman (dmnewman) wrote :

I think there's some confusion here.

For ABC HDTV, these are the same PIDs which I found for Sydney, using
the technique recommended in the linux tv wiki at

http://www.linuxtv.org/wiki/index.php/Scan

They have the same effect as before - no sound in me-tv on the HD
channel which uses AC3 audio.

They are working for Dale because he's using "mplayer", not "me-tv".
They also work for me when I use "mplayer" or "totem-xine", but not in
"me-tv".

This "me-tv" bug is to do with handling of the AC3 PIDs. The fact that
"scan" doesn't find the AC3 PIDs correctly is an issue for the dvb-utils
package, not for "me-tv". Meanwhile, the recommendation in the wiki
lets us work round the "scan" problem, as does Dale's technique, but
does not fix the "me-tv" problem.

Hope this helps,
Daniel

on 16/11/07 23:18 Michael Lamothe said the following:
> Thanks Dale. Daniel, can you confirm if this works for you? I tried
> using the AC3 PIDs that xine gave me but that didn't work. This
> could've been for many reasons though.
>
> Thanks,
>
> Michael
>
>

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Hi Daniel,

That's the outcome that I would've expected. Maybe the DVB streams in
Adelaide are different somehow. Like I said, I get the same result in
Canberra, no audio on HD channels.

Dale, can you think of why you can get audio on all HD channels? Are
you sure that they are AC3?

Thanks,

Michael

On 17/11/2007, Daniel Newman <email address hidden> wrote:
> I think there's some confusion here.
>
> For ABC HDTV, these are the same PIDs which I found for Sydney, using
> the technique recommended in the linux tv wiki at
>
> http://www.linuxtv.org/wiki/index.php/Scan
>
> They have the same effect as before - no sound in me-tv on the HD
> channel which uses AC3 audio.
>
> They are working for Dale because he's using "mplayer", not "me-tv".
> They also work for me when I use "mplayer" or "totem-xine", but not in
> "me-tv".
>
> This "me-tv" bug is to do with handling of the AC3 PIDs. The fact that
> "scan" doesn't find the AC3 PIDs correctly is an issue for the dvb-utils
> package, not for "me-tv". Meanwhile, the recommendation in the wiki
> lets us work round the "scan" problem, as does Dale's technique, but
> does not fix the "me-tv" problem.
>
> Hope this helps,
> Daniel
>
> on 16/11/07 23:18 Michael Lamothe said the following:
> > Thanks Dale. Daniel, can you confirm if this works for you? I tried
> > using the AC3 PIDs that xine gave me but that didn't work. This
> > could've been for many reasons though.
> >
> > Thanks,
> >
> > Michael
> >
> >
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a bug assignee.
>

Changed in me-tv:
status: Confirmed → In Progress
Revision history for this message
Dale (quail-linux) wrote :

Hi Michael,

Under mplayer is showing the audio for HD channels to be this:
==========================================================================
Forced audio codec: mad
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================

Regards
Dale

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

I was just looking at the klear code for something unrelated and I noticed that they are not using DMX_PES_OTHER for audio channels. i.e. I've run out of ideas for this.

Thanks,

Michael

Revision history for this message
Dale (quail-linux) wrote :

Hi Michael,

iirc klear does not work with HD channels anyway, but I would have to
reload in on a computer and test it.

Regards
Dale

On Nov 29, 2007 9:50 PM, Michael Lamothe <email address hidden> wrote:
> I was just looking at the klear code for something unrelated and I
> noticed that they are not using DMX_PES_OTHER for audio channels. i.e.
> I've run out of ideas for this.
>
> Thanks,
>
> Michael
>
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
[WWW] http://southernvaleslug.org/
[IRC] #southern-vales.lug on irc.freenode.net
"The significant problems we face cannot be solved at the same level of
 thinking we were at when we created them"
 Albert Einstein

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

I'll be implementing a full DVB parser rather than just an EIT (Event) parser in 0.5.0. The issue of Me TV selecting the wrong PID type will be fixed then.

Changed in me-tv:
milestone: station-4 → station-5
Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :
Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Well, implementing the auto-scanning did not help. I'm out of ideas. I will have to sit on this until I can think of something else to try.

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Daniel,

All of a sudden my HD Channels started working. Not sure that it's something that I did. Can you please test in 0.5.3?

Thanks,

Michael

Revision history for this message
Matthew Vermeulen (mattvermeulen) wrote :

No change... Would rescanning channels.conf using me-tv help at all?

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Sorry, Nope, that won't help. Thanks for trying. I think that Prime
(that's 9 I think) must've switched the audio method they where using.

On 15/01/2008, Matthew Vermeulen <email address hidden> wrote:
> No change... Would rescanning channels.conf using me-tv help at all?
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a bug assignee.
>

Revision history for this message
Dale (quail-linux) wrote :

the HD channels audio still not work for me here in 0.5.3

On Jan 15, 2008 7:00 AM, Michael Lamothe <email address hidden> wrote:
> Sorry, Nope, that won't help. Thanks for trying. I think that Prime
> (that's 9 I think) must've switched the audio method they where using.
>
> On 15/01/2008, Matthew Vermeulen <email address hidden> wrote:
> > No change... Would rescanning channels.conf using me-tv help at all?
> >
> > --
> > problems with Australian (Sydney) HD channels
> > https://bugs.launchpad.net/bugs/160447
> > You received this bug notification because you are a bug assignee.
>
> >
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
[WWW] http://southernvaleslug.org/
[IRC] #southern-vales.lug on irc.freenode.net
"The significant problems we face cannot be solved at the same level of
 thinking we were at when we created them"
 Albert Einstein

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Hi Dale, I thought that they did work for you?

Revision history for this message
Dale (quail-linux) wrote :

They only work for me using mplayer all along, but the only HD channel
that has ever worked in Me TV is SBS HD

On Jan 15, 2008 9:31 AM, Michael Lamothe <email address hidden> wrote:
> Hi Dale, I thought that they did work for you?
>
> ** Changed in: me-tv/stable
> Status: Fix Committed => In Progress
>
> --
>
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
[WWW] http://southernvaleslug.org/
[IRC] #southern-vales.lug on irc.freenode.net
"The significant problems we face cannot be solved at the same level of
 thinking we were at when we created them"
 Albert Einstein

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Same.

On 15/01/2008, Dale <email address hidden> wrote:
> They only work for me using mplayer all along, but the only HD channel
> that has ever worked in Me TV is SBS HD
>
> On Jan 15, 2008 9:31 AM, Michael Lamothe <email address hidden> wrote:
> > Hi Dale, I thought that they did work for you?
> >
> > ** Changed in: me-tv/stable
> > Status: Fix Committed => In Progress
> >
> > --
> >
> > problems with Australian (Sydney) HD channels
> > https://bugs.launchpad.net/bugs/160447
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
> [WWW] http://southernvaleslug.org/
> [IRC] #southern-vales.lug on irc.freenode.net
> "The significant problems we face cannot be solved at the same level of
> thinking we were at when we created them"
> Albert Einstein
>
> --
> problems with Australian (Sydney) HD channels
> https://bugs.launchpad.net/bugs/160447
> You received this bug notification because you are a bug assignee.
>

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Got it! Needed to set PES filters for the PMT and PAT tables after reading in the PAT/PMT sections. This must help the xine engine determine the types of streams available. Will be available in 0.5.10,

Revision history for this message
Michael Lamothe (lamothe-deactivatedaccount-deactivatedaccount) wrote :

Available in 0.5.10 RC1

Revision history for this message
Daniel Newman (dmnewman) wrote :

Yes! It works well on the HD channels, and seems quite stable (at least
for as long as I could bear to watch sunday morning tv in Sydney).

Thanks for a great program. It's just what my gnome desktop needs.

on 03/02/08 00:21 Michael Lamothe said the following:
> Available in 0.5.10 RC1
>
> ** Changed in: me-tv/stable
> Status: Fix Committed => Fix Released
>
>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.