Hi,
Since upgrading to VDR-1.7.4 I have experienced some instability when
recording to an NTFS partition.
The recording itself seems to proceed OK, but the recorded programs will
generally only play for a few seconds before freezing. Pausing live
video and then resuming play will also trigger the problem. Subsequently
rewinding a recording that has been so paused will only rewind to the
pause point, not the beginning of the recording.
All works well when using vdr-1.7.2 to record on …
[View More]the same system to the
same partition, and when I placed my recording directory on a reiserfs
partition all worked well too. So it appears to be
a problem recording on NTFS partitions introduced with the switch to .ts
file recording.
Any help appreciated.
Mark.
This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscribe(a)au.fujitsu.com
[View Less]
On Mon, Mar 16, 2009 at 05:23:53PM +0200, Antti Palosaari wrote:
> Heinrich Langos wrote:
>>
>> Anyway .. the main problem remains.
>>
>> Is there a tool that would only do some minimal actions on a dvb
>> device?
>
> Like power_on? femon for example reads device status. zap, scan...
>
I cleaned up my system a little more to reduce the avg wakups per second.
Now, when vdr is not started I get about 5 wakeups per second and only
about 0.2-0.3% of the …
[View More]time is spent in C0 (cpu running).
Now starting "femon" I get the following outut at about one line per second:
| jukebox:/tmp/hgaf9015.MPZgGXIerw/af9015-a57ea2073e77# femon -H
| FE: Afatech AF9013 DVB-T (DVBT)
| status SCVYL | signal 18% | snr 0% | ber 0 | unc 6073 | FE_HAS_LOCK
| status SCVYL | signal 18% | snr 0% | ber 0 | unc 6073 | FE_HAS_LOCK
| status SCVYL | signal 18% | snr 0% | ber 0 | unc 6073 | FE_HAS_LOCK
| ...
The avg wakups per second go up to about 30, time spent in C0 is slightly
higher with 0.4 - 0.6%.
Now starting "zap" to tune into a channel:
| jukebox:/tmp/hgaf9015.MPZgGXIerw/af9015-a57ea2073e77# zap -channels /tmp/channel.conf N24
| Using frontend "Afatech AF9013 DVB-T", type DVB-T
| status SCVYL | signal 0000 | snr 0014 | ber 00000000 | unc 000017b9 | FE_HAS_LOCK
Now the wakups per second go up up about 3000 and the cpu is running in C0
about 30% of the time!
I ran "dvbtraffic" (itself causing about 10 wakups but hardly any cpu load)
on another console to see what is happening and it seems like "femon" does
only check the receiver's status while "zap" realy causes data to be transfered
from the USB device to the host.
So the rather heavy load that I see with vdr is probably not caused by vdr
itself but by the USB data transfer.
The new questions are:
Does every USB DVB-T receiver cause the same amount of cpu load?
Does vdr need to read the data stream all of the time?
Can it be switched off? (At least while nobody watches and EPG data
is not refreshed?)
cheers
-henrik
[View Less]
On Mon, Mar 16, 2009 at 05:23:53PM +0200, Antti Palosaari wrote:
> Heinrich Langos wrote:
>> On Mon, Mar 16, 2009 at 03:07:21PM +0100, Heinrich Langos wrote:
>>> On Mon, Mar 16, 2009 at 02:19:30PM +0200, Antti Palosaari wrote:
>>>> remote=0 does not disable polling, it is for selecting correct remote.
>>> Well, setting remote=0 does have an effect (af9015.c):
>>>
>>> if (val == AF9015_IR_MODE_DISABLED || val == 0x04) {
…
[View More]>>> af9015_properties[i].rc_key_map = NULL;
>>> af9015_properties[i].rc_key_map_size = 0;
>
> val is read from eeprom, there is byte in eeprom which tells whether
> device have remote or not. If eeprom says no remote then polling is
> disabled.
> If you look more carefully there is if-else condition which goes:
> if (eeprom remote disabled)
> * disable remote
> else if (module param remote defined)
> * load ir-table defined as module param
> else
> * load ir-table according to USB-ID
>
You are right. Sorry I didn't read that carefully enough.
> I am not sure what happens if device have remote but ir-table is not
> selected by if-else. Probably .rc_key_map_size leaves to 0 and remote
> polling is disabled.
Thats exactly what happens. Though, I didn't see a place where
af9015_properties[i]rc_key_map is initalized. Maybe a sanity check
for the "remote" module parameter should be added? Telling the user that
he uses an invalid value could help new users.
> Anyhow, this problem is not af9015 specified. Most dvb-usb -drivers have
> just similar implementation. rc-polling is provided by dvb-usb-core.
Right again. Sorry to bother you.
>> Anyway .. the main problem remains.
>>
>> Is there a tool that would only do some minimal actions on a dvb
>> device?
>
> Like power_on? femon for example reads device status. zap, scan...
Yeap. Thank you for that list. I'll take a look at those and see what I can
find out.
Cheers and thank you very much for your help!
-henrik
[View Less]
Hi
My issues.
May be I not right, but....
1. Have: use section filtering - "yes", disable filters - 0.
Have a iptv channel in channel.conf, but absent and not streaming now.
Switch channels: work channnel -> absent channel -> work channel.
And vdr hangs, almost always....
If set use section filtering - "no", all works.
If set use section filtering - "yes", disable filters - 1, PAT, all works too.
2. pat.c use Channels.GetByServiceID.
Channels.GetByServiceID use ISTRANSPONDER().
#…
[View More]define ISTRANSPONDER(f1, f2) (abs((f1) - (f2)) < 4)
We must use frequencies differ > 4 in iptv channels.
TV1;IPTV:1:IPTV|S1P0|UDP|127.0.0.1|1234:P:0:512:650:2321:0:1:0:0:0 - third parametr.
Never use:
TV1;IPTV:1:IPTV|S1P0..............
TV1;IPTV:2:IPTV|S1P0..............
TV1;IPTV:3:IPTV|S1P0..............
need use (example):
TV1;IPTV:10:IPTV|S1P0..............
TV1;IPTV:20:IPTV|S1P0..............
TV1;IPTV:30:IPTV|S1P0..............
Otherwise ISTRANSPONDER() not works correct...
[View Less]
Hei Antti,
On Mon, Mar 16, 2009 at 02:19:30PM +0200, Antti Palosaari wrote:
> Heinrich Langos wrote:
>> That is with dvb_usb_af9015 loaded but with "remote=0" module parameter
>> to disable the remote control input that aparently is done by polling.
>
> remote=0 does not disable polling, it is for selecting correct remote.
Well, setting remote=0 does have an effect (af9015.c):
if (val == AF9015_IR_MODE_DISABLED || val == 0x04) {
…
[View More]af9015_properties[i].rc_key_map = NULL;
af9015_properties[i].rc_key_map_size = 0;
While every other (valid) value for "remote" assigns a key map at that point
and further sets the af9015_config.ir_table. I guess thats has consequences
so that even if polling occurrs, it doesn't cause a whole lot of other
actions.
> You can disable polling by setting proper module param for module dvb-usb.
Where "proper" would be? :-)
>> (With "remote=2" it goes up by about 50 wakeups per second. OK, AFAIK
>> USB input devices need to be polled. No way around it. But does it have
>> to be at 20ms intervals?)
>
> hmm, It should be 150ms according to the code. No idea why it generates
> 50 wakeups.
My guess would be that each polling action generates several USB packets
which in turn cause several wakeups...
> I have no idea why.
Does your vdr let your machine sleep nicely?
Cheers
-henrik
[View Less]
Hi Klaus,
I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still
present in version 1.7.3 but the behaviour is worst because it segfaults.
First I found out that 2 lines where added in the ParsePmt method.
Data += Data[0] + 1; // this is the first packet
Length -= Data[0] + 1;
At the moment I don't know exactly what is the meaning of this 2 operations.
The second line can result in a negative Length which is the reason of the
segfault.
Could you kindly …
[View More]explain the offset drift? In a single section PMT (99.9% of
the time) Data[0] is always equal to 0 and we skip the first byte. Length is
reduced by 1. I a multiple section stream Data[0] can be above 188. Trying to
skip more than a section is not possible in the actual context.
I have done a quick and dirty hack to prevent the segfault:
--- remux.c_ori 2009-01-16 21:05:46.000000000 +0100
+++ remux.c 2009-01-17 13:34:17.000000000 +0100
@@ -361,6 +361,7 @@
if (pmtSize == 0) {
Data += Data[0] + 1; // this is the first packet
Length -= Data[0] + 1;
+ if ( Length < 0 ) Length = 0;
if (SectionLength(Data, Length) > Length) {
if (Length <= int(sizeof(pmt))) {
memcpy(pmt, Data, Length);
the second step will be to have the parsing of multiple section allowed. At
the moment when the data size exceed the section size (max 4096), PMT cannot
be parsed.
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: PMT section length too big (4176 byte)!
[2222] ERROR: can't parse PMT
Regards,
Alex
[View Less]
Hi,
I just installed vdr 1.6.0 on Debian stable (Lenny). I run it on an old
notebook (Dell 1300, 1.5 GHz Celeron M).
Up until now the system was a network storage for some windows clients and a
music player for my living room. Now I plan to use vdr as a remote
controled VCR.
To keep it quiet I checked with powertop and got rid of most software that does
short idle loops. Now the system shows less than 10 wakeups per second from
sleep.
That is with dvb_usb_af9015 loaded but with "remote=…
[View More]0" module parameter
to disable the remote control input that aparently is done by polling.
(With "remote=2" it goes up by about 50 wakeups per second. OK, AFAIK USB
input devices need to be polled. No way around it. But does it have to be
at 20ms intervals?)
Anyway, the real fun comes with starting vdr. With vdr runing I get a
whopping 2700 wakeups per second! And thats doing nothing at all. No recording,
no playback no streaming. Nada! The result is a 30% CPU load (admittetly at a
low P-state) and a constantly runing CPU fan.
I don't know what vdr does, but it causes the device to jump through a lot of
(idle) loops. At least thats what I'd read from the output of powertop.
Does anybody have an idea as to what it causing this?
Any comparative data for other devices?
I also own a "Fujitsu-Siemens DVB-T Mobile TV Tuner" and I'll
take a look and try to find out if that device will generate
less system load.
Cheers
-henrik
Here's the idle state without vdr:
=================================
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0.2%) 750 Mhz 0.0%
polling 0.0ms ( 0.0%) 563 Mhz 0.0%
C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0%
C2 0.0ms ( 0.0%) 188 Mhz 100.0%
C3 102.8ms (99.8%)
Wakeups-from-idle per second : 9.7 interval: 20.0s
no ACPI power usage estimate available
Top causes for wakeups:
38.1% ( 4.9) <interrupt> : uhci_hcd:usb3, eth0
15.6% ( 2.0) xfsaild : schedule_timeout (process_timeout)
13.2% ( 1.7) xfsbufd : schedule_timeout (process_timeout)
7.8% ( 1.0) ifconfig : b44_open (b44_timer)
5.1% ( 0.7) <kernel core> : sk_reset_timer (tcp_delack_timer)
5.1% ( 0.7) mpd : sk_reset_timer (tcp_write_timer)
3.9% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn)
1.9% ( 0.2) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer)
1.9% ( 0.2) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer)
1.6% ( 0.2) runsvdir : schedule_timeout (process_timeout)
1.6% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog)
1.6% ( 0.2) init : schedule_timeout (process_timeout)
0.8% ( 0.1) screen : do_setitimer (it_real_fn)
0.8% ( 0.1) nmbd : schedule_timeout (process_timeout)
0.4% ( 0.1) <kernel core> : neigh_add_timer (neigh_timer_handler)
0.4% ( 0.1) <kernel core> : queue_delayed_work (delayed_work_timer_fn)
0.4% ( 0.1) xfssyncd : schedule_timeout (process_timeout)
=================================
and here's the "idle" state with vdr:
=================================
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) (29.4%) 750 Mhz 0.0%
polling 0.0ms ( 0.0%) 563 Mhz 0.0%
C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0%
C2 0.0ms ( 0.0%) 188 Mhz 100.0%
C3 0.2ms (70.5%)
Wakeups-from-idle per second : 2878.8 interval: 10.0s
no ACPI power usage estimate available
Top causes for wakeups:
60.2% (4431.3) USB device 5-1 : DVB-T 2 (Afatech)
39.4% (2897.7) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel
0.1% ( 7.7) klogd : ehci_work (ehci_watchdog)
0.1% ( 5.1) vdr-kbd : schedule_timeout (process_timeout)
0.1% ( 4.4) <interrupt> : uhci_hcd:usb3, eth0
0.1% ( 3.7) vdr-kbd : futex_wait (hrtimer_wakeup)
0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout)
0.0% ( 1.6) xfsbufd : schedule_timeout (process_timeout)
0.0% ( 1.0) ifconfig : b44_open (b44_timer)
0.0% ( 0.9) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout)
0.0% ( 0.6) <kernel core> : sk_reset_timer (tcp_delack_timer)
0.0% ( 0.6) mpd : sk_reset_timer (tcp_write_timer)
0.0% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn)
0.0% ( 0.3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer)
0.0% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog)
0.0% ( 0.2) xfssyncd : schedule_timeout (process_timeout)
0.0% ( 0.2) runsvdir : schedule_timeout (process_timeout)
0.0% ( 0.2) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer)
0.0% ( 0.2) init : schedule_timeout (process_timeout)
0.0% ( 0.1) syslogd : do_setitimer (it_real_fn)
0.0% ( 0.1) nmbd : schedule_timeout (process_timeout)
=================================
[View Less]
Thank you for your responses. I would be happy for any help offered and
would gladly share any results I come up with. If anyone wants my diffs
for building xinelib/vdr-fbe on PCH, please mail me.
For me, the overall goal is:
- Get the functionality of a full VDR frontend on PCH
The current tech. idea is;
- Use mono to display audio/video
- Use custom directfb app to display xineliboutput VDR OSD and
get lirc input
The initial tasklist as I see it:
- Test mono with xineliboutput http …
[View More]access
- Make a simple directfb app displaying some image and see
if it can show it ontop of a running mono av-stream.
- Hack vdr-fbfe/xinelib wildly to get OSD from xineliboutput
onto PCH.
- Possibly rewrite without using xinelib.
It might be good to locate the 'project' somewhere with a decent Wiki
and SVN repository. Please suggest something.
Please note though that the time I can put on this is very limited, my
VDR adventures is a very slow moving process, with family, house and
work taking up most of my time.
/Johan
--
Johan Andersson, jna(a)jna.pp.se
[View Less]
Hi all,
In case you have a high resolution output device (LCD/Plasma) you probably
noticed that image
plugin show low quality results even when the original image is a very high
quality/resolution.
To fix it, replace the following lines in liboutput/encode.c file from:
m_nWidth = 720;
m_nHeight = m_bUsePAL ? 576 : 480;
to
m_nWidth = 1920;
m_nHeight = 1080;
Or other output resolution if you don't have a full HD screen.
Developers of image plugin, it would be great to …
[View More]have those 2 parameters
configurable for that plugin.
Also, I've noticed the xinelibout (or OSD) stuck many times when I use image
plugin.
And another improvement:
Since image conversion takes lots of time (about 2-3 seconds on E6600) it
will be great if the plugin will
try to cache next or previous image (depends on user direction) in advance,
so the switch will be instant.
Converting 9 images to show the 3x3 screen takes VERY long. Maybe should
convert them to a very
low resolution images to make is faster.
Beside that, thanks for a good plugin.
[View Less]