Hello!
I upgraded my VDr system from 1.6.0 to 1.7.16. After upgrade, I found that my FF card (fujitsu-siemens dvb-c) crashes almost every time when I exit from a recording playback. It won't tune anymore. Usually OSD still works but sometimes it also crashes. Only way to recover is to restart VDR and reload kernel module. I'm using latest fw for ff card.
Ps. For some reason sc plugin doesn't work either with ff card even I have forced to transfer mode from sc plugin menu and started it with -B switches. Maybe it is related to this crash?
- - cart@live.fi writes:
Hi,
Same issue here. I was thinking it was an issue with the card, the firmware, the motherboard or pci latency. In the end I stopped using it... I'm even considering giving it to someone else.
The only plugins i'm using are xineliboutput and streamdev and I'm able to make it crash by just changing channels. Dish and signal are ok, no errors and my budget and dvb-s2 card are both working perfectly.
That's a very good thing i read your message, i'll try to use 1.6.0 and see if it's ok with it :)
Cheers.
I've got a couple FF cards that work fine, although I've used them as budget cards ever since I moved to a VDPAU setup.
VDR User user.vdr@gmail.com writes:
I've got a couple FF cards that work fine, although I've used them as budget cards ever since I moved to a VDPAU setup.
Hi,
do you mean you have modified your ff card as explained on http://www.linuxtv.org/wiki/index.php/DVB_TT_Budget_Patch ?
Do you use to have arm crashes or/and "unknown picture type" errors before ? I have also considered modifying my ff card but i'm not sure if it will fix my issues.
Any advice or feedback on that matter would really be helpful.
On Thu, Feb 10, 2011 at 5:13 AM, syrius.ml@no-log.org wrote:
No, my FF cards are unmodified. I mean that I'm not using the FF aspect -- I don't use the onboard decoder or tv output. I switched to VDPAU for decoding (back when VDPAU was developed against the xine-lib-1.1 tree), and the video cards output obviously. This was long before VDR-1.7.16 and FF support moved into a plugin ("dvbsddevice" in VDR-1.7.11).
Do you use to have arm crashes or/and "unknown picture type" errors before ?
I experienced arm crashes a very long time ago (years) and it was due to firmware, but since it was fixed there hasn't been any. I've never got an "unknown picture type" error.
Your card should work as is with no modifications necessary. My only advice is that you use the current firmware and driver. Maybe there's a bug in the dvbsddevice plugin? That's the only thing I can think of since there's no doubt FF cards work fine with VDR-1.7.16 when used as budget cards.
I'm have been using a Technotrend FF sat card on 1.7.16 without a problem.
Check you are using the latest firmware.
MD.
I upgraded my VDr system from 1.6.0 to 1.7.16. After upgrade, I found
that my
FF card (fujitsu-siemens dvb-c) crashes almost every time when I exit
from a
recording playback. It won't tune anymore. Usually OSD still works but sometimes it also crashes. Only way to recover is to restart VDR and
reload
kernel module. I'm using latest fw for ff card.
Hi,
Same issue here. I was thinking it was an issue with the card, the firmware, the motherboard or pci latency. In the end I stopped using it... I'm even considering giving it to someone else.
The only plugins i'm using are xineliboutput and streamdev and I'm able to make it crash by just changing channels. Dish and signal are ok, no errors and my budget and dvb-s2 card are both working perfectly.
That's a very good thing i read your message, i'll try to use 1.6.0 and see if it's ok with it :)
Cheers.
"Hawes, Mark" MARK.HAWES@au.fujitsu.com writes:
:-)
Ok, i'll give it a last try with another motherboard and also with vdr-1.6.0 and I'll give it away.
Hello!
I have found in my DVB-C system that there seems to be lot of lipsync problems. Also in live broadcast! Usually it occurs when I exit from recording playback. I'm using ubuntu 10.04.
Am Mittwoch, den 09.02.2011, 22:13 +0200 schrieb - -:
Have you tried this firmware: http://escape-edv.de/endriss/firmware/ ?
But even with that firmware you must not switch to a DVB-S2 Channel, since that will crash your card in any case.
Have you tried this firmware: http://escape-edv.de/endriss/firmware/ ?
I'm using that firmware.
But even with that firmware you must not switch to a DVB-S2 Channel, since that will crash your card in any case.
So far we don't have had dvb-s2 channels in our cable dvb-c network ;P.
Found something in my log:
Feb 9 23:29:06 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:06 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:07 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:07 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:10 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:10 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:11 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:11 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:13 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:13 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:14 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:14 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:16 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:16 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:17 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:17 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:18 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:18 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:19 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:19 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:20 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:20 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:21 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:22 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:23 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:23 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:29:25 htpc vdr: [1815] frontend 1/0 lost lock on channel 20, tp 402 Feb 9 23:29:25 htpc vdr: [1815] frontend 1/0 regained lock on channel 20, tp 402 Feb 9 23:30:58 htpc vdr: [1815] frontend 1/0 timed out while tuning to channel 0, tp 177 Feb 9 23:31:37 htpc vdr: [1815] frontend 1/0 lost lock on channel 109, tp 242 Feb 9 23:31:39 htpc vdr: [1815] frontend 1/0 timed out while tuning to channel 109, tp 242 Feb 9 23:31:52 htpc vdr: [1815] frontend 1/0 regained lock on channel 49, tp 250 Feb 9 23:31:53 htpc kernel: [13123.832018] av7110_fw_request: timeout waiting for COMMAND to complete Feb 9 23:31:53 htpc kernel: [13123.840126] dvb-ttpci: StopHWFilter error cmd 0b08 0001 0000 ret ffffff92 resp fb28 c8df pid 18 Feb 9 23:31:54 htpc kernel: [13124.848018] dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle Feb 9 23:31:54 htpc kernel: [13124.864207] dvb-ttpci: av7110_fw_request error -110 Feb 9 23:31:54 htpc kernel: [13124.872244] dvb-ttpci: StopHWFilter error cmd 0b08 0001 0001 ret ffffff92 resp 0296 0020 pid 0 Feb 9 23:31:55 htpc kernel: [13125.880017] dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle Feb 9 23:31:55 htpc kernel: [13125.896086] dvb-ttpci: av7110_fw_request error -110 Feb 9 23:31:55 htpc kernel: [13125.904224] dvb-ttpci: StopHWFilter error cmd 0b08 0001 0002 ret ffffff92 resp 0296 0020 pid 17 Feb 9 23:31:56 htpc vdr: [1815] frontend 1/0 lost lock on channel 49, tp 250 Feb 9 23:31:56 htpc vdr: [1815] frontend 1/0 regained lock on channel 49, tp 250 Feb 9 23:31:56 htpc kernel: [13126.912019] dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle Feb 9 23:31:56 htpc kernel: [13126.928376] dvb-ttpci: av7110_fw_request error -110 Feb 9 23:31:56 htpc kernel: [13126.936482] dvb-ttpci: StopHWFilter error cmd 0b08 0001 0003 ret ffffff92 resp 0296 0020 pid 16 Feb 9 23:31:56 htpc kernel: [13126.937528] dvb-ttpci: ARM crashed @ card 1 Feb 9 23:31:56 htpc kernel: [13126.950814] dvb 0000:00:13.0: firmware: requesting av7110/bootcode.bin Feb 9 23:31:56 htpc vdr: [1816] ERROR: can't set filter (pid=18, tid=40, mask=C0): Operation not permitted Feb 9 23:31:56 htpc vdr: [1816] ERROR: can't set filter (pid=0, tid=00, mask=FF): Operation not permitted Feb 9 23:31:56 htpc vdr: [1816] ERROR: can't set filter (pid=17, tid=42, mask=FF): Operation not permitted Feb 9 23:31:56 htpc vdr: [1816] ERROR: can't set filter (pid=16, tid=40, mask=FF): Operation not permitted Feb 9 23:31:56 htpc kernel: [13126.989556] dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle 0000 Feb 9 23:31:56 htpc kernel: [13126.989992] dvb-ttpci: StartHWFilter error buf 0b07 0010 0000 b96a ret -1 handle 0000 Feb 9 23:31:56 htpc kernel: [13126.990329] dvb-ttpci: StartHWFilter error buf 0b07 0010 0011 b96a ret -1 handle 0000 Feb 9 23:31:56 htpc kernel: [13126.990651] dvb-ttpci: StartHWFilter error buf 0b07 0010 0010 b96a ret -1 handle 0000 Feb 9 23:31:57 htpc kernel: [13127.444081] dvb-ttpci: DVB-C w/o analog module @ card 1 detected Feb 9 23:31:57 htpc vdr: [1815] frontend 1/0 lost lock on channel 49, tp 250 Feb 9 23:31:59 htpc vdr: [1815] frontend 1/0 timed out while tuning to channel 49, tp 250 Feb 9 23:32:22 htpc vdr: [1815] frontend 1/0 timed out while tuning to channel 43, tp 274 Feb 9 23:32:43 htpc vdr: [1815] frontend 1/0 timed out while tuning to channel 116, tp 298
Udo Richter udo_richter@gmx.de writes:
Hi,
Are you still using it as a primary device with its mpeg decoder and video output ? I've been trying to use it in transfer mode only for a long time and it has been recurrently crashing. (need to unload/reload dvb-ttpci, in some rare case need to restart computer)
This is an old rev1.5 card, I guess it was never meant to be used like this.
Am 14.02.2011 01:33, schrieb syrius.ml@no-log.org:
Yes, its still the primary output device. I'm using it together with an budget SAT card. The card does live view, playback and transfer mode, using the VDR 1.7 TS output device mode.
When recording using both devices, I make sure that output is suspended, to avoid bandwidth overloads. Thats the only issue I have.
This is an old rev1.5 card, I guess it was never meant to be used like this.
r1.6 card using fe2624 firmware, stock debian backports 2.6.32-bpo.5 kernel. Last reboot in december, right after installing the kernel.
Cheers,
Udo
-
- - -
Eric C
-
Falk Spitzberg -
Hawes, Mark -
syrius.ml＠no-log.org -
Udo Richter -
VDR User