Hello everyone,
I just talked to Genka about the vdr-portal.de server outage.
The machine has been transfered to a new location this weekend, and
apparantly they still have problems to get it running.
He told me that he is in close contact with the technicians, but there
currently is no statement when the service will be back again.
If I get new information I'll relay it either here or on the startpage
of www.vdr-wiki.de
Cheers
Thomas
Hello,
I'm use VDR on my server with a DVB-S card. I use it to stream TV
channels and record TV shows. Recording works great for SD channels, but
is broken for HD channels.
Whenever I ask it to record a HD TV show, it starts recording (but the
.ts file doesn't grow in size) and after 30 seconds it terminates
unexpectedly. It says the video data stream is broken, but it's actually
fine! There are no problems with watching HD channels streamed from VDR...
I suggest VDR should stop taking care …
[View More]about the stream correctness and
should just start recording. Because until then vdr-streamdev-server and
wget are the only working combo.
Aside from that I don't understand why it terminates completely if it
_thinks_ some bad data arrived. Data errors may happen at any time and
it's not a valid reason for an emergency exit.
This one's an encrypted DVB-S2 channel, I've tried the FTA BBC HD too
and it terminated as well.
The syslog:
Nov 14 11:55:26 hera vdr: [10024] switching device 1 to channel 8
Nov 14 11:55:26 hera vdr: [10024] timer 5 (8 1133-1340 'Rande s
celebritou') start
Nov 14 11:55:26 hera vdr: [10024] Title: 'Rande s celebritou' Subtitle:
'(Win a Date with Tad Hamilton!) Dívce z malého města Kate Bosworth,
posedlé hvězdnou slávou, se splní sen! Vyhraje rande se svým idolem
filmového plátna a on ji začne zbožňovat. Jejímu nejlepšímu příteli se to'
Nov 14 11:55:26 hera vdr: [10024] record
/var/lib/video.00/Rande_s_celebritou/2010-11-14.11.33.8-0.rec
Nov 14 11:55:26 hera vdr: [10024] cFileName::SetOffset: removing
zero-sized file
/var/lib/video.00/Rande_s_celebritou/2010-11-14.11.33.8-0.rec/00001.ts
Nov 14 11:55:26 hera vdr: [10024] recording to
'/var/lib/video.00/Rande_s_celebritou/2010-11-14.11.33.8-0.rec/00001.ts'
Nov 14 11:55:26 hera vdr: [10056] recording thread started (pid=10024,
tid=10056)
Nov 14 11:55:26 hera vdr: [10035] timer 1 (8 1133-1340 'Rande s
celebritou') set to event Ne 14.11.2010 11:35-13:30 'Rande s celebritou'
Nov 14 11:55:57 hera vdr: [10056] ERROR: video data stream broken
Nov 14 11:55:57 hera vdr: [10056] initiating emergency exit
Nov 14 11:55:57 hera vdr: [10024] emergency exit requested - shutting down
Nov 14 11:55:57 hera vdr: [10024] stopping plugin: streamdev-server
Best regards,
--
Luboš Doležel
[View Less]
Hi,
I'm in a desperate crusade to get vdr 1.6.0 working properly _again_
with Sky on a FF Nexus-S rev2.3 with original CI/Alphacrypt Classic CAM
and a betacrypt based Sky subscription.
Being a long time vdr user (since about 2002), I rearranged my setup to
better fit my family needs. Since my server is running 24/7 for other
reasons anyway, I added two WinTV-HVR4000 and a Nexus-S 2.3 with CI/CAM
to it. OS is a openSUSE 11.1/i586 with a collection of newer kernels:
2.6.34.5, 2.6.34.7, 2.…
[View More]6.36, the sat input is from a Kathrein EXR 508/T
switching matrix, located nearby the server and feeded by a Quad-LNB.
The sat installation was done completely by a professional.
Before the switch to server based vdr, I used older vdr versions with
older SuSEs in a single "home video theater" setup (apart from NFS
based recording), and after some fiddling, it worked great for many
years (it took unloading and reloading the dvb drivers on startup
before running vdr in order to get the CAM operational reliably). We
never used another set top box for TV watching since the very
beginning. Even my wife fully acknowledged the system (which is quite
hard to archive for _any_ electronic equipment, BTW..).
Since the very first server setup, I have stability problems with Sky
recordings. It manifests in either:
1) no proper CAM detection: VDR shows CAM exists/vorhanden instead of
AlphaCrypt (no recordings possible at all)
2) proper CAM detection: but totally distorted recordings with many PES
error messages in vdr log
3) dropouts in recordings (vdr restarts with no apparent reason) until
final break-down with behaviour as described in 1)
1) could be alleviated with the dvb driver unload/reload trick (I'm
using an init script, that loads a given list of dvb drivers on start
and unloads them in reverse order on stop. The driver list is not
complete due to a bug in cx8802, that cannot be unloaded until the
newest kernel versions, but that only affects the (at the moment
uninteresting) WinTV-HVR4000 part:
http://www.mail-archive.com/linux-media%40vger.kernel.org/msg23580.html)
Sometimes a pull/push of the CAM fixes it for a certain time, but this
is not an acceptable concept for obvious reasons.
2) This might be due using to an older AlphaCrypt firmware, and didn't
happen anymore after update to 3.20.
3) happens massively now. See VDR log link below.
I already tried to lay the 80 wire ribbon optimally between the Nexus
and the CI (no kinks, etc).
My AlphaCrypt settings:
CAM 1: 'AlphaCrypt 3.20 (c) Mascom GmbH'
CAM 1: 'Modul Einstellungen'
CAM 1: 'Sprache/Language: DEUTSCH'
CAM 1: 'Smartkarten Meldungen: AUS'
Slot 1: <== Text Last (5) 'CA-Systeme: SINGLE (nur von Smartkarte)'
Slot 1: <== Text Last (5) 'CA-Anmeldung: DYNAMIC (immer erneuern)'
Slot 1: <== Text Last (5) 'Erzwinge Lesen originale PMT: AUS'
Slot 1: <== Text Last (5) 'CA-PMT L366schzeit: 0 s '
Slot 1: <== Text Last (5) 'CI-Fehler374berwachung: 1500 ms '
Slot 1: <== Text Last (5) 'dbox Kompatibilit344t: EIN '
The vdr version, I using here is available here:
https://build.opensuse.org/project/show?project=home%3Afrispete%3Avdr
It's using the usual patches 1.6.0-{1,2} from Klaus, and the usual
adjustments due to gcc and kernel compatibility. Don't let the
vdr-1.6.0-2_extensions.diff.gz perturb you, the problems happen with
and without applying it. My build does enable DebugProtocol in ci.c
(with sed in the spec)..
Today, we tried to enjoy Sebastian Vettels thriller/victory on Sky, but
miserably failed due to continued drop outs and multiple break-downs.
The full disaster is reflected by the logs below.
In short, the logs are flooded with countless messages like:
Nov 14 21:46:46 tyrex vdr: [8632] Slot 1: no module present
Nov 14 21:46:46 tyrex vdr: [8632] CAM 1: no module present
Nov 14 21:46:47 tyrex vdr: [8632] Slot 1: module present
Nov 14 21:46:47 tyrex vdr: [8632] CAM 1: module present
Nov 14 21:46:59 tyrex vdr: [8632] Slot 1: no module present
Nov 14 21:46:59 tyrex vdr: [8632] CAM 1: no module present
Nov 14 21:46:59 tyrex vdr: [8632] Slot 1: module present
Nov 14 21:46:59 tyrex vdr: [8632] CAM 1: module present
Nov 14 21:47:16 tyrex vdr: [8643] streamdev-server: Detaching current
receiver
Nov 14 21:47:16 tyrex vdr: [8643] streamdev-server: Detaching current
receiver
Nov 14 21:47:16 tyrex vdr: [8643] streamdev-server: Detaching current
receiver
and peppered with:
Nov 14 22:07:31 tyrex vdr: [25348] cAudioRepacker(0xC1): skipped 1148
bytes while syncing on next audio frame
Nov 14 22:07:31 tyrex vdr: [25348] cAudioRepacker(0xC0): skipped 1148
bytes while syncing on next audio frame
only finally leading to a vdr restart, that results in state 1).
What am I do wrong? Is this really such a dead road as it looks right
now? I considered switching to 1.7, but if I'm unable to get this to
work properly within a pure SD environment, how can additional HD and
other complexity solve this (without adding a lot of others issues all
over the plate).
DVB driver reload: ftp://urpla.net/dvb.log
VDR log: ftp://urpla.net/vdr.log
VDR log from 12:00 to 22:16 today: ftp://urpla.net/vdr-full.log
full boot log: ftp://urpla.net/boot.msg
Let me know, if I can provide more infos.
Any hints to solve this problem are highly appreciated.
TIA,
Pete
[View Less]
(Sorry for not responding using my mailer's Reply function, I didn't
realize I couldn't do that in the digest mailing list mode.)
After enabling the debugging options in remux.c as was suggested, all I
got was a load of forward slashes in console output until it terminated.
I failed to find any other useful debugging output.
////////////////////////////////////////////////grabbing event
/////////////////////////////////////////////////[more slashes]
frame duration = 3600 FPS = 25.00 …
[View More]FPPU = -2
/////////////////////////////////////////////////[more slashes]
frame duration = 3600 FPS = 25.00 FPPU = -2
/////////////////////////////////////////////////[more slashes]
# (terminated)
The one-line patch provided here didn't help, I dare say it even can't,
because the TV programs I have problems with are in H.264 and not in
MPEG-2, in the switch branch of which the altered line is located.
So if this is a problem related to I frames, I suppose we should tinker
with the following line:
independentFrame = Data[i + 1] == 0x10;
Regards,
--
Luboš Doležel
[View Less]
Hi!
You might have noticed already, that projects.vdr-developer.org is not
reachable right now.
The whole vdr-developer.org domain seems to be gone. Let's hope it
hasn't expired and some stupid domain grabber gets his hands on it.
I've already contacted Siegmar at vdrportal.de (he's the domain holder).
Meanwhile you can access projects.vdr-developer.org temporary under
this address:
http://community.xeatre.tv/
Sorry for the inconvenience! I hope this gets solved soon.
Tobias
Right now when the needs of a vdr extension goes beyond core SVDRP
capabilities a different approach is being used by the each extensions.
Prominent examples are:
- vdradmin (using native SVDRP and suffering from its performance,
optional use of direct file access to epg data)
- live-plugin (integrating into vdr as plugin)
- vdr iphone remote (using native SVDRP and due the bad performance and
encryption capabilities an optional web-based interface)
(and I'm sure there are more)
While this …
[View More]is not bad per se there is obviously room for improvement. So
my idea was to introduce a new standardized interface to VDR (either as
plugin or native SVDRP commands) to plugins/extensions offering:
- encryption (to be able to use it remotely in a more secure fashion)
- compression (to overcome performance limitations especially when large
amount of epg data have to be transferred)
- and optionally authentication for obvious reasons
Now I would like to start a few discussions related to this topic, the
ones that come to my mind mind first are:
- Should this be implemented as plugin or in core vdr as svdrp extension?
- Would Klaus accept patches if this will be native SVDRP?
- Are developers/maintainers of current or feature plugins/extensions
interested in such a solution?
- What technical implementation would make most sense?
- Who would be willing to contribute to such a project?
For the first step I was thinking about adding a "STARTTLS" command to
core vdr (as patch) handling encryption and maybe also tranparent
compression. This taks should be fairly easy as we could borrow ideas or
even code from existing projects using STARTTLS (like mail servers).
Authentication however would require a major redesign as far as I can tell.
German version of this discussion can be found here:
http://www.vdrportal.de/board/thread.php?threadid=101357
Thanks for your feedback,
Christian
[View Less]
Hello,
I'm trying to understand cSdtFilter in order to write a channel scanner.
I see that when it finds a SI::NVODReferenceDescriptorTag it will add it
to the previously found channel with channel->SetLinkChannels, but it
only does if it is in the current section (channel is a local variable)
while the sdt could span several sections.
From the specifications here
http://neuron2.net/library/mpeg2/iso13818-1.pdf
and here
http://www.dvb.org/technology/standards/a005r5.tm1324r13.…
[View More]tr101211.v1.10.1.p…
I don't understand if this mechanism is correct, shouldn't the
"time_shifted_services" link to the "NVOD_reference"?
Besides, I don't see that the relation between a channels and its
linkchannels is preserved in channels.conf (though I don't really care).
I also see that cSdtFilter starts processing with the first section, and
that shouldn't really be necessary as long as one processes all sections.
Bye
--
Luca
[View Less]