XBMC spielt keine PVRInput Kanäle, aber auch andere Frontends funktionieren ok

Swifty

Ich habe dies an der xvdr Github angemeldet, aber wenn jemand Hilfe anbieten kann, es wäre toll!

Ich habe VDR mit dem Plugin pvrinput und verwenden Sie es mit einer Hauppauge HD-PVR-und Kabel-Box.
Es stimmt gut mit streamdev-Player auf meinem Android-Handy und funktioniert mit VDR-sxfe ok, aber wenn ich spielen mit XBMC / xvdr das Video startet versuchen, ist alles was ich sehe das Zwischenspeichern-Leiste am oberen Rand des Bildschirms, und bleiben Sie saß LiveTV auf dem EPG-Fenster. (die HD-PVR ist mit der Aufnahme beginnen, da die es leuchtet auf der Oberseite)

Ich habe xvdr mit DEBUG = 1 neu kompiliert und hier ist das Protokoll von VDR nach ein paar Versuchen, um einen Kanal in XBMC starten; http://pastebin.com/ztPPpHcZ
Sie können am Ende sehen, wenn ich spielen einen Kanal, durch XBMC, die kurz nach xine Melodien ein Kanal selbst (der letzte, den ich sah) und scheint einen Video-Stream in Ordnung erkennen zu stoppen ..

Hier ist ein Debug-Log von XBMC beim Versuch, einen Kanal zu starten; http://pastebin.com/20k4uyeG
Und schließlich ist ein VDR-Log von erfolgreichen Start eines Kanals über streamdev und mein Android-Handy - nur sofern es etwas gibt, nützlich; http://pastebin.com/n5h1MgBj

Ich hoffe, dass diese als nützlich erweisen, wie ich es lieben würde, um diese Arbeit zu bekommen!
Lassen Sie mich wissen, ob es etwas anderes kann ich testen ..

----

I have logged this at the xvdr github, but if anyone can offer help it would be great!

I have VDR with the pvrinput plugin and use it with a Hauppauge HD-PVR and cable box.
It tunes fine with streamdev player on my Android phone and works ok with VDR-SXFE, but when I try to play using XBMC/XVDR the video never starts, all I see is the buffering bar at the top of the screen, and stay sat on the LiveTV EPG window. (the HD-PVR does start to record, since the it lights up on the top)

I have re-compiled XVDR with DEBUG=1 and here is the log from VDR after a few attempts to start a channel in XBMC; http://pastebin.com/ztPPpHcZ
You can see at the end, when I stop playing a channel through XBMC, that shortly after xine tunes a channel itself (the last one I watched) and seems to detect a video stream ok..

Here is a debug log from XBMC while trying to start a channel; http://pastebin.com/20k4uyeG

And lastly is a VDR log from successfully starting a channel via streamdev and my android phone - just incase there is anything useful; http://pastebin.com/n5h1MgBj

I hope these prove useful as I would love to get this working!
Let me know if there is anything else I can test..

Dr. Seltsam

I have very few experience with xbmc...

Does the problem only exists when using xbmc for viewing Live-TV? Can you replay a pvrinput recording with xbmc which was made with vdr?

PS: Don't try to use a translator - it makes no sense

Swifty

Zitat von Dr. Seltsam

Does the problem only exists when using xbmc for viewing Live-TV? Can you replay a pvrinput recording with xbmc which was made with vdr?

Well, oddly VDR doesn't seem to want to start recording for some reason - it just seems to be ignoring all timers, there not even any acknowledgement in the logs that a timer was just supposed to start..
But, if I cat the output of the HD-PVR to a .ts file, then I can play it in XBMC OK.

Zitat von Dr. Seltsam

PS: Don't try to use a translator - it makes no sense

I thought it might be garbage but I appreciate this is a primarily German speaking forum, so thought it was only courteous hehe

Dr. Seltsam

Did you compile vdr + pvrinput yourself or do you use packages? Which versions?

Please set the loglevel in pvrinput to 4 and stop vdr. Then start vdr, tune to a pvrinput channel and start a recording manually. Stop the recording and vdr after 10s. Then post the log file.
It would be easier if you could use only the necessary plugins (pvrinput and the output plugin) in order to keep the log small.

Swifty

Thanks for your assistance.

I've disabled the other plugins from loading and manually added a timer which now seems to be trying to record

I've put the pvrinput log to level 4 as requested, and when tailing the log for VDR I can see it's crashing VDR shortly after trying to start the record - it seems to point at; ERROR: video data stream broken.

However, I can cat the output from the HD-PVR to a .ts file and it's growing in size (the VDR recording is always 0kb since it never seems to see any video)

I can't confirm if the HD-PVR is lighting up blue on the top when trying to start this recording, since I'm doing it all remotely at the moment from work over SSH...

I'm using VDR 1.7.27 from the YAVDR Precise PPA (testing IIRC).

Here is the log (pastebin seems down for me at the moment) ; http://codepad.org/PRDQdHl2

Cheers

mini73

Hi,

I think it's a driver bug. Someone posted it months ago on the linux-media mailing list[1].
The driver returns from "select" which means, there's data available for reading but the "read" call blocks - that should not happen.
Maybe you have more luck than Rob if you you "reanimate" his thread... Posting problems at linux-media is not much fun.

Lars.
[1] http://thread.gmane.org/gmane.linux.drivers.dvb/48378

Swifty

Thanks Lars,

I just read the posts, and it sounds like it could be something I will encounter, but I'm not 100% sure if it's the same issue - since Rob sounds like his was working for the most part at least.. whereas mine refuses to make ANY recording or playback through XVDR.

I have been searching around with the error message and most seem to point at wrong PID/VID details - could someone confirm if the following channels.conf excerpt is correct for VDR 1.7.27 ?

Code

Discovery Channel:212:COMPONENT:V:0:4113+4097=27:0;4352=@106:0:0:212:1:9011:0 
Discovery Channel +1:213:COMPONENT:V:0:4113+4097=27:0;4352=@106:0:0:213:1:9011:0 
Animal Planet:215:COMPONENT:V:0:4113+4097=27:0;4352=@106:0:0:215:1:9011:0 
Discovery History:217:COMPONENT:V:0:4113+4097=27:0;4352=@106:0:0:217:1:9011:0 
Discovery Science:219:COMPONENT:V:0:4113+4097=27:0;4352=@106:0:0:219:1:9011:0

I used the example from here and simply duplicated it changing the channel name and numbers as I went, but after re-checking my channels.conf just now I seem to have extra things that have been added (I assume by VDR) such at @106 etc... I'm not sure what these mean?!

The 212,213,215,217,219 values are needed to that the external channel switch script works - hopefully I put them in the right place

It's a really odd problem, since if I use VDRManager (Android) which connects via Streamdev then tuning is working OK... so I'm not sure

--- EDIT ---

Hmmm.... I just duplicated an exisiting channel line and fixed it to exactly match the example from the github page, I ensured UpdateChannels was set to 0 and started VDR - I then stopped it and checked the channels.conf, and the line now has the =@106; added

mini73

Hi,

I think, "@106" is the audio type or something similar. That's ok.
"UpdateChannels = 0" will ensure that the name and PIDs of the channels will not change.
But since the PIDs are in the TS of the HD PVR, vdr would set the right ones in the channel (if firmware or driver would change them in the future).
A higher value of UpdateChannels should be ok.

After all the channels look good but I don't have such a box. The integration of it into pvrinput was a lot trial & error.

But if streamdev etc. works ok then xvdr seems to make something different. Haven't looked into that plugin yet...

Lars.

Dr. Seltsam

The frequency for external inputs should be 1, so all channel conf entries must start with "HD PVR:1:"
Every channel should have a unique SID (not always 9011). The external channel is defined by the last three digits of the SID. Have a look in externchannelswitch.sh.example :

Bash

#!/bin/bash




# set to true to enable debugging output
DEBUG="true"




declare SID="$1"
declare VDRCHANNEL="$2"
declare VIDEONUMBER="$3"
declare FREQUENCY="$4"
declare EXTERNCHANNEL
let "EXTERNCHANNEL = SID % 1000" #last three digits from SID without leading 0


#exec dct6200 "$EXTERNCHANNEL"


if test "$DEBUG" == "true"; then
 logger -s  "DEBUG pvrinput externchannelswitch: Variable SID has value \"$SID\""
 logger -s  "DEBUG pvrinput externchannelswitch: Variable VDRCHANNEL has value \"$VDRCHANNEL\""
 logger -s  "DEBUG pvrinput externchannelswitch: Variable VIDEONUMBER has value \"$VIDEONUMBER\""
 logger -s  "DEBUG pvrinput externchannelswitch: Variable FREQUENCY has value \"$FREQUENCY\""
 logger -s  "DEBUG pvrinput externchannelswitch: Variable EXTERNCHANNEL has value \"$EXTERNCHANNEL\""
fi

Alles anzeigen

But I think this is not the problem. Please try using the box without external channel script. Make sure, the box gets a clean video signal from your external receiver before starting vdr. I know that the HD-PVR Encoder has problems with changing input signals.
Each time the resolution changes, the box initializes itself and may get stucked.

Swifty

Thanks for the help guys.

I will do some more tests when I get home in an hour or so and let you know how it goes

Swifty

Ok, I had some time to do some more testing last night.

I have fixed all my channels in the channels.conf so I have unique SID's and the first numeric value is set to 1.

I managed to get a successful recording via VDR of a PVR channel, and it plays back fine with XBMC (I actually scheduled it via XBMC too)

However, after stopping the recording, and trying another with a different channel, the HD-PVR didn't light up, and VDR started doing it's emergency exit loop again..

I've loaded the very latest (1.7.1 I think) firmware to the HD-PVR, as it mentioned that it fixes an issue where the PCR is sometimes incorrect (I'm not sure if that matters to VDR at all?) but this didn't help.

So, currently I've installed MythTV to see if it's any happier working with the HD-PVR (though I'd really like to use VDR!) but I guess it will help to highlight if its a VDR problem or something in the HD-PVR driver...

Dr. Seltsam

Does frequently stopping and starting a recording on the same channel (without changing it) work reliable?

Try adding

Code

pvrinput.ExternChannelSwitchSleep = 1

in /var/lib/vdr/setup.conf
This means "sleep x seconds after call of externchannelswitch.sh". Try values from 1 to 5. Maybe the box needs some time to stabilize after a channel switch before the encoder is ready again.

Dr. Seltsam

Zitat

However, after stopping the recording, and trying another with a different channel, the HD-PVR didn't light up, and VDR started doing it's emergency exit loop again..

a vdr log with log level 4 from pvrinput would be helpful.

For normal testing you should use a pvrinput log level of 1.

Swifty

Thanks for the suggestions, I'll check these out tonight and get back to you

Swifty

Ok, so some more testing tonight with VDR - I now have pretty reliable ability to record.

I'm not sure exactly, but I think I should have powered down the HD-PVR after changing the firmware version, I did this earlier and now without any further changes in VDR I have recorded 8 different channels OK, even without any sleep after channel switch.

I can play all the recordings just fine in XBMC.

Here (http://pastebin.com/pEJe6Pr0) is a log at level 4 - It doesn't seem much more verbose than before.. I assume all info goes to /var/log/syslog?

The log shows, a timer being added, and starting ok - then I tried to tune to the same channel that was already recording in XBMC, but as with normal LiveTV channels that aren't recording I just got the buffering indicator at the top of the screen

I tried to stop / start the same channels (so it didn't re-tune the cable box) but that didn't help.. I also tried to add the external switch sleep values (1>5) and there was still no difference.

I confirmed again that using VDR-SXFE or Streamdev that the same channels work OK.

Jetzt mitmachen!