2010-12-02, 12:54
Told you his builds would probably work 
2010-12-02, 12:59
nssk Wrote:Told you his builds would probably work
Streamdev was clearly my issue previously! And not being able to get VNSI working was me being an idiot not changing my VNSI allowed hosts file correctly.
Time to see how stable this build is. I used to get a few random crashes on pvr-testing2.
2010-12-02, 17:34
I'd like to report a bug in VNSI server, dunno if it's the right place for it.
When I zap to some channel, i don't have sound. If I open the audio menu on this channel i can see around 10 audio tracks, instead of 2 or 4, depending if channel have ac3 or not.
As example, Canal+ from cable:
The stream has 4 audio tracks, 2 ac3 and 2 mp2 ( one each for fr and en ).
In xbmc menu, i can see 11 tracks. 2 first ones are fake chans, then track 3,4,5,6 have the sound, then 7,8,9,10,11 are fake.
Those fakes trakcs are not supposed to exist. I don't have this problem with Streamdev, or tvheadend ( and not on vdr side of course ) .
When tuning from xbmc-pvr to thise channel it gives me this on the log:
That's a really annoying bug as default audio track always a fake one.
I thought first the bug came from a bad ttxtsub patch, then i tryed a vanilla vdr with only vnsi running, but it gives me the same problem.
Tested with vdr-1.7.15 and vdr-1.7.16
Is it an identified problem and does somebody has it too ?
Thanks.
When I zap to some channel, i don't have sound. If I open the audio menu on this channel i can see around 10 audio tracks, instead of 2 or 4, depending if channel have ac3 or not.
As example, Canal+ from cable:
The stream has 4 audio tracks, 2 ac3 and 2 mp2 ( one each for fr and en ).
In xbmc menu, i can see 11 tracks. 2 first ones are fake chans, then track 3,4,5,6 have the sound, then 7,8,9,10,11 are fake.
Those fakes trakcs are not supposed to exist. I don't have this problem with Streamdev, or tvheadend ( and not on vdr side of course ) .
When tuning from xbmc-pvr to thise channel it gives me this on the log:
Code:
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 0:0 with codec_id 94215
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 1:1 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 2:2 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 3:3 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 4:4 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 5:5 with codec_id 86016
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 6:6 with codec_id 86016
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 7:7 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 8:8 with codec_id 2
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 9:9 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 10:10 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 11:11 with codec_id 86020
16:21:34 T:2936011632 M:1012051968 DEBUG: CDVDDemuxPVRClient::UpdateStreams(): update stream 12:12 with codec_id 86020That's a really annoying bug as default audio track always a fake one.
I thought first the bug came from a bad ttxtsub patch, then i tryed a vanilla vdr with only vnsi running, but it gives me the same problem.
Tested with vdr-1.7.15 and vdr-1.7.16
Is it an identified problem and does somebody has it too ?
Thanks.
2010-12-06, 17:07
@dushmaniac
Do you know if there's anyone out there looking to fix the Streamdev issue?
I'm using your build with VNSI and it works fine except for one problem. Not sure if this is a VDR VNSI problem or an XBMC VNSI plugin problem.....
Channels that time share a slot on a DVB-T multiplex only appear in the channel list when they're actually broadcasting. This means I have channels appearing and disappearing throughout the day. If a channel appears whilst my HTPC is on it is added to the bottom of the list. As you can imagine this is a bit irritating because it ruins any channel ordering and numbering that has been defined.
Do you know if there's anyone out there looking to fix the Streamdev issue?
I'm using your build with VNSI and it works fine except for one problem. Not sure if this is a VDR VNSI problem or an XBMC VNSI plugin problem.....
Channels that time share a slot on a DVB-T multiplex only appear in the channel list when they're actually broadcasting. This means I have channels appearing and disappearing throughout the day. If a channel appears whilst my HTPC is on it is added to the bottom of the list. As you can imagine this is a bit irritating because it ruins any channel ordering and numbering that has been defined.
2010-12-06, 18:16
Hi. Stop vdr server and edit in /etc/vdr/channels.conf which cahnnels and which order you want your channels to be. after that change in your /etc/vdr/setup.conf UpdateChannels=3 to UpdateChannels=2 and start vdr again.
2010-12-06, 19:19
tume2 Wrote:Hi. Stop vdr server and edit in /etc/vdr/channels.conf which cahnnels and which order you want your channels to be. after that change in your /etc/vdr/setup.conf UpdateChannels=3 to UpdateChannels=2 and start vdr again.
That doesn't fix it. It was already set as 2 after I previously wanted to stop VDR adding new channels that weren't originally listed in my scanned channels.conf file
My channels.conf is already setup as I want, with all the channels I need.
It seems VNSI only allows access to currently broadcasting channels, whereas streamdev just lists them all.
2010-12-07, 02:06
dushmaniac Wrote:@ant_thomas
afaik nobody is doing anything for the vdr plugins
I thought as much.
I guess I'll have to wait for Dharma to be released and see what's going on in terms of the PVR/LiveTV side of things.
2010-12-14, 01:27
I'm guessing there won't be an answer or even an idea why it happens, but the VNSI issue of channels not always appearing is worse than I thought.
The channels that appear later in the day end up at the bottom of the list but won't work. They end up having the same number as existing channels because other channels take their places.
What needs to be done is clearing the database to get the channels back in place.
I'm assuming this is a VNSI issue rather than XBMC?
The channels that appear later in the day end up at the bottom of the list but won't work. They end up having the same number as existing channels because other channels take their places.
What needs to be done is clearing the database to get the channels back in place.
I'm assuming this is a VNSI issue rather than XBMC?
2010-12-14, 10:39
I heard that other clients are showing the same behaviour when coming out of suspend.
when does this behaviour occur for you? could you post a full debug log of the event?
when does this behaviour occur for you? could you post a full debug log of the event?
2010-12-14, 13:04
dushmaniac Wrote:I heard that other clients are showing the same behaviour when coming out of suspend.
when does this behaviour occur for you? could you post a full debug log of the event?
I'll get you one tonight when there's the biggest change in channels.
To explain fully my channels.conf file defines my channel order as (the first few)..
Code:
1 - BBC ONE
2 - BBC TWO
3 - ITV1
4 - Channel 4
5 - FIVE
6 - ITV2
7 - ITV2+1
8 - BBC THREE
9 - BBC FOUR
10 - ITV3
11 - ITV4But because BBC THREE and FOUR don't broadcast before 7PM if I was to turn my XBMC system on now (11AM) the order within XBMC would be...
Code:
1 - BBC ONE
2 - BBC TWO
3 - ITV1
4 - Channel 4
5 - FIVE
6 - ITV2
7 - ITV2+1
8 - ITV3
9 - ITV4The non-broadcasting channels disappear and the rest move up to fill the space.
After 7 PM the channels would appear at the bottom of the list...
Code:
1 - BBC ONE
2 - BBC TWO
3 - ITV1
4 - Channel 4
5 - FIVE
6 - ITV2
7 - ITV2+1
8 - ITV3
9 - ITV4
...
...
...
40...
41...
8 - BBC THREE
9 - BBC FOURBut they aren't useable because they are using the same number as another channel (if at this point I select BBC THREE, ITV3 would play instead). It also messes up the EPG listings so clearing the database and enabling and disabling TV is required, at which point everything is put back into order and works.
It is definitely a VNSI issue because it didn't happen with streamdev on pvr-testing2.
2010-12-14, 22:06
2010-12-15, 19:32
It's a different problem, but should be fixed after I finished work in the pvr-refactor branch.
It'll end up in my master branch and won't be fixed in Dharma-pvr anymore.
It'll end up in my master branch and won't be fixed in Dharma-pvr anymore.
2010-12-15, 20:39
dushmaniac Wrote:It's a different problem, but should be fixed after I finished work in the pvr-refactor branch.
It'll end up in my master branch and won't be fixed in Dharma-pvr anymore.
That's great to know it might be fixed. I'll hop on over to the Master branch at some point. Are there any benefits of being on the Master branch now over the Dharma branch?
2010-12-16, 00:51
dushmaniac Wrote:It's a different problem, but should be fixed after I finished work in the pvr-refactor branch.
It'll end up in my master branch and won't be fixed in Dharma-pvr anymore.
Hi, dushmaniac. Great work.
I have one very big problem with streamdev: I can't play live channels, and I have several "QualitySignal" messages, Error 500 "LSTQ" command not recognized everytime I try to play LiveTV.
In this very same thread (http://forum.xbmc.org/showpost.php?p=491...tcount=502) pkrzaczk told us that a couple of patches are required (streamdev-cvs221109-AddFemonV1.diff and streamdev-cvs221109-AddCallbackMsg.diff).
What I am not sure is if those patches apply to streamdev-client or streamdev-server.
Would you be so kind to tell us what the problem is, and how to solve it, in case you know about it?
Regards.
