I lost my temper with crashes with dxr3, and now I have DVB-S FF (Technotrend 1.3) to be used as output only. Here are pros and cons:
+ display is not getting messed with OSD/mp3 plugin + no more hard crashes where conputer needs reset. VDR watchdog takes care
- Jammed and killed by watchdog all the time. I had problems with DXR3, but now usability is worse. After pressing back from viewing recoderd program 50% it gets jammed and watchdog restart. There was recording running at the same time, and also noad running (with nice). - Picture, all colors are too bright. I need to adjust brigtness, color and contrast (and still not happy). I suppose this would need some module parameter, but did not had time to study this far. - After boot vdr thinks volume is 0, and when I start adjusting volume, for 0.5s it is FULL, then it gets to where it should be.
My system is P350, 224M memory, vdr 1.3.23, 2.4 kernel, dvb-kernel drivers from CVS ~2 weeks ago (needed CVS version for Airstar2)
I was expecting to get stable usable system by getting FF card, but no way. Any ideas what might the problem be:
- Too slow CPU - 2.4 kernel, everybody uses 2.6 ? - Using DVB-S as output only is bad idea - Bad HW (computer or DVB-FF) - Bad DVB driver version - Bad VDR version - Bad luck - Nothing broken, this is the way it is for everybody. I should use more M$-products to get to used crashes
En/na Markku Tavasti ha escrit:
- Too slow CPU
I cannot say, because when I built my vdr the minimum cpu I could find was a 1600MHz Duron (underclocked to 1400), way oversized for the task at hand. I managed to get the dxr3 more or less working with a pentium 100 though (only for testing purposes, not very useable, but that's probably because that machine has only 16megs of ram).
- 2.4 kernel, everybody uses 2.6 ?
I'm using 2.6, cannot tell about other dxr3 users
- Using DVB-S as output only is bad idea
- Bad HW (computer or DVB-FF)
Considering that many people here manage to get a dxr3 working, albeit with some problems but not the complete lock-up you reported, I'd say this is the most probable cause...
- Bad DVB driver version
- Bad VDR version
- Bad luck
...or this one ;-) I'd rule out the vdr version, since I'm also using 1.3.23
Bye
Luca Olivetti luca@ventoso.org writes:
- 2.4 kernel, everybody uses 2.6 ?
I'm using 2.6, cannot tell about other dxr3 users
But the point is, even with DVB-FF it does not work like at least I would expect...
I'd rule out the vdr version, since I'm also using 1.3.23
And question is also about patches. I use pre-packaged version, and it says:
vdr-patchlevel: enAIO-2.1 jumpplay-0.6 subtitles-ttxtsubs director sharelnb update-resume setup-show-valid submenu disableDoubleEpgEntrys_0.7.1 noepg wareagle-icons timer-info_wareagle
Argh, should I still swich to hand-compiled. Ok, now without dxr3 I can just grab pached package with plugins here:
http://almamedia.fi:8000/~sjm/vdr/
Markku Tavasti a écrit :
My system is P350, 224M memory, vdr 1.3.23, 2.4 kernel, dvb-kernel drivers from CVS ~2 weeks ago (needed CVS version for Airstar2)
I was expecting to get stable usable system by getting FF card, but no way. Any ideas what might the problem be:
- Too slow CPU
The cost of a new mobo + modern CPU would be much less than your disappointment. I can tell that, but I also plan to revamp an old Celeron 466 + DXR3 into a brand new carputer... without any (much) add-on cost...
- 2.4 kernel, everybody uses 2.6 ?
You have the typical VDR setup, particularly the one Klaus uses, so it should be safe.
- Using DVB-S as output only is bad idea
- Bad HW (computer or DVB-FF)
Test your memory with memtest (or memtest86) and your CPU with cpuburn. Both will also stress the chipset. You will be confident after that (or you'll have replaced a few chips). This old computer could very well hurt you. No systematic test for the DVD card, though.
- Bad DVB driver version
- Bad VDR version
- Bad luck
Or bad compiler, bad package source, bad dependencies. Did you try precompiled packages only, or at the contrary only self-compiled plackages and plug-ins ?
- Nothing broken, this is the way it is for everybody. I should use more M$-products to get to used crashes
Nicolas Huillard nhuillard@e-dition.fr writes:
The cost of a new mobo + modern CPU would be much less than your disappointment.
Problem is noise. Modern CPU requires more cooling which makes more noise. Silencing needs expensive case. So we end up to something like 400E for total cost. Ok, that is not so bad, but if it does not help, it is bad. That's why I'm asking. I don't want to spend money and time fixing something which is not broken.
Or bad compiler, bad package source, bad dependencies. Did you try precompiled packages only, or at the contrary only self-compiled plackages and plug-ins ?
I've used self compiled earlier (1.3.22 and 1.3.17). Pre-compiled seems bit slower, but don't really know since those were with dxr3, and on every step dxr3 driver & plugin version changed also. So results are not comparable..
I'll try memtest and cpuburn. I've tried memtest few month ago, and no problems found.
Markku Tavasti a écrit :
Nicolas Huillard nhuillard@e-dition.fr writes:
The cost of a new mobo + modern CPU would be much less than your disappointment.
Problem is noise. Modern CPU requires more cooling which makes more noise. Silencing needs expensive case. So we end up to something like 400E for total cost. Ok, that is not so bad, but if it does not help, it is bad. That's why I'm asking. I don't want to spend money and time fixing something which is not broken.
The solution for this is the EPIA boards. Particularly the fanless ones. You'll get at least 600Mhz on a modern platform, with less heat than your P350... Around 150€, fits in any case your P350 was in. But if you don't need it, don't buy it.
Markku Tavasti wrote:
I lost my temper with crashes with dxr3, and now I have DVB-S FF (Technotrend 1.3) to be used as output only. Here are pros and cons:
- display is not getting messed with OSD/mp3 plugin
- no more hard crashes where conputer needs reset. VDR watchdog takes care
- Jammed and killed by watchdog all the time. I had problems with DXR3, but now usability is worse. After pressing back from viewing recoderd program 50% it gets jammed and watchdog restart. There was recording running at the same time, and also noad running (with nice).
- Picture, all colors are too bright. I need to adjust brigtness, color and contrast (and still not happy). I suppose this would need some module parameter, but did not had time to study this far.
- After boot vdr thinks volume is 0, and when I start adjusting volume, for 0.5s it is FULL, then it gets to where it should be.
My system is P350, 224M memory, vdr 1.3.23, 2.4 kernel, dvb-kernel drivers from CVS ~2 weeks ago (needed CVS version for Airstar2)
I was expecting to get stable usable system by getting FF card, but no way. Any ideas what might the problem be:
...
- Using DVB-S as output only is bad idea
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Oliver
Oliver Endriss o.endriss@gmx.de writes:
- Using DVB-S as output only is bad idea
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Great. 1.3 DVB-S FF for sale. Brand new, only tested for few days.
:-(
On Monday 25 April 2005 13:59, Markku Tavasti wrote:
Oliver Endriss o.endriss@gmx.de writes:
- Using DVB-S as output only is bad idea
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Nope - need to call FE_SLEEP after init of frontend (requires driver patch), works since years stable for me.
Guido Fiala gfiala@s.netic.de writes:
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Nope - need to call FE_SLEEP after init of frontend (requires driver patch), works since years stable for me.
Pointer to patch, or patch itself would be welcome. I could not find it with google (wrong keywords in search).
On Monday 25 April 2005 17:09, Markku Tavasti wrote:
Guido Fiala gfiala@s.netic.de writes:
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Nope - need to call FE_SLEEP after init of frontend (requires driver patch), works since years stable for me.
Pointer to patch, or patch itself would be welcome. I could not find it with google (wrong keywords in search).
Ok, once again i try to collect what i did, i changed 3 files, although 2 would probably do:
required (dvb-kernel): frontend.h (make FE_SLEEP public to be able to call it via ioctl)
requried (vdr): dvbdevice.c (calls FE_SLEEP, it did not work when the FE_INIT was never called, we need to FE_INIT and after that call FE_SLEEP to make it work)
not sure (dvb-kernel): ves1x93.c (mainly debug-output to see if it works plus one register-change which alone did not make it work, as far as i remember)
Attached are the diff's of the changes i made. Of course you cannot use the patches when you use a dish, it is only good for signalless operation. (Obsessively using playmode switches+OSD occasionally arm-crashs anyway, sigh)
Hope it fixes your problems.
Guido Fiala gfiala@s.netic.de writes:
requried (vdr): dvbdevice.c (calls FE_SLEEP, it did not work when the FE_INIT was never called, we need to FE_INIT and after that call FE_SLEEP to make it work)
Your patch has only that FE_SLEEP ? And I can't call for FE_INIT in dvbdevice.c?
Ok, anyway I prefer vdr would be untouched, so I try to make needed changes to driver part only. FE_SLEEP is simple enough, so integrating it to INIT would not be so hard.
Let's see.
Markku Tavasti wrote:
I lost my temper with crashes with dxr3,
If I understand the purpose of the xine and framebuffer plugins correctly, they, too, are alternatives to dxr3. Have you tried them as well? Are they more stable?
I'm just curious because I might want to move *away* from the FF card in the future because of ARM crashes, low bandwidth and high price.
Carsten.
On Monday 25 April 2005 18:31, Markku Tavasti wrote:
Guido Fiala gfiala@s.netic.de writes:
requried (vdr): dvbdevice.c (calls FE_SLEEP, it did not work when the FE_INIT was never called, we need to FE_INIT and after that call FE_SLEEP to make it work)
Your patch has only that FE_SLEEP ? And I can't call for FE_INIT in dvbdevice.c?
Ok, anyway I prefer vdr would be untouched, so I try to make needed changes to driver part only. FE_SLEEP is simple enough, so integrating it to INIT would not be so hard.
I tried that myself and it seemed not to work (although it should, logically), but i might have made something wrong. Please let me/us know if you get it working with the driver change alone.
Guido
On Mon, Apr 25, 2005 at 05:47:10PM +0200, Guido Fiala wrote:
On Monday 25 April 2005 17:09, Markku Tavasti wrote:
Guido Fiala gfiala@s.netic.de writes:
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Nope - need to call FE_SLEEP after init of frontend (requires driver patch), works since years stable for me.
Pointer to patch, or patch itself would be welcome. I could not find it with google (wrong keywords in search).
Ok, once again i try to collect what i did, i changed 3 files, although 2 would probably do:
required (dvb-kernel): frontend.h (make FE_SLEEP public to be able to call it via ioctl)
requried (vdr): dvbdevice.c (calls FE_SLEEP, it did not work when the FE_INIT was never called, we need to FE_INIT and after that call FE_SLEEP to make it work)
Why not just patch vdr to close the frontend fd? The driver will then call FE_SLEEP automatically.
Johannes
Johannes Stezenbach wrote: ...
Why not just patch vdr to close the frontend fd? The driver will then call FE_SLEEP automatically.
Good idea. That could even become part of the SourceCaps patch by simply closing the frontend fd when the list of sources for a certain card is empty. Since Klaus mentioned long ago that he will incorporate the SourceCaps feature into standard VDR, no patching at all would be required this way.
Carsten.
Carsten Koch a écrit :
Markku Tavasti wrote:
I lost my temper with crashes with dxr3,
If I understand the purpose of the xine and framebuffer plugins correctly, they, too, are alternatives to dxr3.
They are.
Have you tried them as well?
Makku said he has a P350, that won't handle the software decoding.
Are they more stable?
Reading the ML, it seems to. Softdevice has reached a really good level these times. Whoever would like to test a simple and efficient alternative to hardware decoding (FF / Dxr3) should test the latest softdevice release 0.1.1. Really impressive : fast response, stable, etc. Softdevice uses one of the 4 output methods : frame-buffer, DirectFB, vidix, Xv. Choose the one that best suits you (frame-buffer is slow an 16 bits only, DirectFB uses video acceleration + alpha, vidix needs root access for specific VGA cards, Xv needs an X server running)
I'm just curious because I might want to move *away* from the FF card in the future because of ARM crashes, low bandwidth and high price.
Test softdevice if you have at least 800Mhz-1Ghz ;-) That's not an easy task, but the result is rewarding.
Guido Fiala wrote:
On Monday 25 April 2005 17:09, Markku Tavasti wrote:
Guido Fiala gfiala@s.netic.de writes:
Very bad idea [tm] if you have a rev. 1.3 DVB-S card. The ARM will crash very often without a sat signal.
Nope - need to call FE_SLEEP after init of frontend (requires driver patch), works since years stable for me.
Well, if you patch the driver you can do anything.
Pointer to patch, or patch itself would be welcome. I could not find it with google (wrong keywords in search).
Ok, once again i try to collect what i did, i changed 3 files, although 2 would probably do: ...
Imho it should be enough to use the attached patch (not tested).
Oliver
Johannes Stezenbach wrote:
Why not just patch vdr to close the frontend fd? The driver will then call FE_SLEEP automatically.
Good point!
Even better: The frontend driver should start in sleep mode, and vdr should not open the frontend...
Maybe a useful setup option for vdr? 'Use primary device for replay only'
Oliver
Markku Tavasti tavasti@iki.fi writes:
- Jammed and killed by watchdog all the time. I had problems with DXR3, but now usability is worse. After pressing back from viewing recoderd program 50% it gets jammed and watchdog restart. There was recording running at the same time, and also noad running (with nice).
Progress this far:
- memtest86 and cpuburn reveal no problems, both run without problems (memtest 2 full rounds, burnP5 1h, burnMMX 10min, burnBX 10min) - Fixed my antenna cable (better signal) - Removed debug messages from vdr (I had -l3) - Changed setting 'update channels' from 'add new transponder' to 'no update' - Tested with no extra programs running (no noad, no rsync over network) and works quite fine. Test was quick, we'll see if it is really stable & usable, but at least it looked much better.
- Picture, all colors are too bright. I need to adjust brigtness, color and contrast (and still not happy). I suppose this would need some module parameter, but did not had time to study this far.
Tried different 'options dvb-ttpci vidmode=X' settings. 0 disables composite video, 3 gives Black&White. 1 and 2 give dark picture with too bright colors. Something wrong with card? Picture was perfect with dxr3.
Markku Tavasti tavasti@iki.fi writes:
- Picture, all colors are too bright. I need to adjust brigtness, color and contrast (and still not happy). I suppose this would need some module parameter, but did not had time to study this far.
Tried different 'options dvb-ttpci vidmode=X' settings. 0 disables composite video, 3 gives Black&White. 1 and 2 give dark picture with too bright colors. Something wrong with card? Picture was perfect with dxr3.
Ok, now even that is fixed. Changing module options+reloading is not working test, tv has to be booted also :-) Looks like vidmode=3 might be correct. At the moment I'm not sure, too bright sunlight to see TV properly.
And I had also problems with getting Hauppauge Nova-T and Technisat Airstar2 working together. Now even that is fixed, it's question of module loading order.
- Skystar2 has to be loaded first - Nova-T has to be next. If Nova-T is after dvb-ttpci, remote won't work - dvb-ttpci last
Resulting modules.conf:
### update-modules: start processing /etc/modutils/dvb alias dvb dvb-ttpci options dvb-ttpci vidmode=3 above dvb-ttpci ves1x93 #add above dvb-ttpci skystar2 add below dvb-ttpci dvb-ttpci-budget-ci add below dvb-ttpci-budget-ci skystar2 above skystar2 mt352 options mt352 force_card=2 above dvb-ttpci-budget-ci tda1004x
Summary:
- For unused DVB-S input don't use setting 'Add new transponder' for channel update, it will make arm crash - For searching correct vidmode=X setting be shure to turn off your tv-receiver between changes - Module loading order *does* matter.
-
Carsten Koch -
Guido Fiala -
Johannes Stezenbach -
Luca Olivetti -
Markku Tavasti -
Nicolas Huillard -
Oliver Endriss