146 replies to this topic

[OldDeuteronomy]

One thing I forgot to mention: When I open the timer list after a recording is interrupted, that recording is still listed as active and running timer. Also the recording indicator on the front display of the box is still indicating a recording. And when pressing the REC key, the first menu option still is to stop the recording. So the box seems to still "think" that it is recording something, while it actually isn't.

[ReneW]

On this not recording issue... I experienced the same, recording something which should be about 2h30 long, and this morning checking there was only 13 minutes recorded, now i did watch it from the start and didnt see any message that there was something wrong, and the tuner had put itself to standby as per timer instructions.

In the box is a Samsung EcoGreen F3 500GB 16MB (SATAII).

The Pli was the updated version of yesterday, 26 december

[OldDeuteronomy]

Yes, same here, as said above, the timer runs completely normal until its scheduled end, but the actual recording stops anytime earlier.


Update regaring recording to a network drive: Fails as well. The test recording I just did was running longer than all other tests I did before, so I already thought it would work, but then it stopped after approx. 30 minutes as well.

[metoo]

same here with vuduo and latest beta2 build

[MiLo]

Just a wild guess: Does it stop at 4GB file size?

[MiLo]

...When I accessed the ET9000 HDD via Windows Explorer...

That's the samba bug, which happens on all machines and not just the et9000. You'll only see files under 4GB, bigger files will "wrap around" at 4GB, for example a 5GB file will show up as 1GB, and 19 GB will probably show up as 3GB.

So please don't use samba in your diagnostics, neither client nor server!

[jedeje]

same here with vuduo and latest beta2 build

That´s interesting, I assume you are referring to the recording problems.

The issue is then no longer isolated to the ET9000.

Gr
JeDeJe

[malakudi]

@Milo: Does PiP work for you with gcc 4.4 drivers and OpenPLI 2.0 beta?

Yes, but only for SD channels. Appears to be a hardware limitation.

This is really weird. For me with OpenPLI 1.0 and drivers from http://www.et-view.c...rs-20101203.zip PiP works fine, 2 SD or 1 HD and 1 SD (as hardware capabilities suggest). With OpenPLI 2.0 beta and drivers from 03/12, 16/12 or latest 26/12 PiP doesn't work at all.

[ReneW]

That's the samba bug, which happens on all machines and not just the et9000. You'll only see files under 4GB, bigger files will "wrap around" at 4GB, for example a 5GB file will show up as 1GB, and 19 GB will probably show up as 3GB.

So please don't use samba in your diagnostics, neither client nor server!

No the 13 minutes of recordings will not even get to 1gb.

To that, is there an option to have the recordings be in parts? With my old IPbox 250, i know that the recordings could be split into segments of 640mb, 1gb, 1.5gb etc.

[OldDeuteronomy]

Just a wild guess: Does it stop at 4GB file size?

That happened exactly once in my case. It was that recording I mentioned earlier that showed up in Windows Explorer with 180MB and via FTP with around 4GB. But all other test recordings I performed so far stopped way earlier than 4GB.

[swiffer]

openpli v1.0, 20101217.

I program a record of Spy Kids2 this morning on BBC One HD, with 1 mn before and 1 mn after. The record is fine (I checked the begin & the end). The size is 5,6 Go.
I use an internal Sata WD Caviar green (1 To, 32 MB cache).

I program another record this afternoon, The Incredibles.

Hope this will help to find the regression introduced in current pli image.

[malakudi]

@Milo: Does PiP work for you with gcc 4.4 drivers and OpenPLI 2.0 beta?

Yes, but only for SD channels. Appears to be a hardware limitation.

This is really weird. For me with OpenPLI 1.0 and drivers from http://www.et-view.c...rs-20101203.zip PiP works fine, 2 SD or 1 HD and 1 SD (as hardware capabilities suggest). With OpenPLI 2.0 beta and drivers from 03/12, 16/12 or latest 26/12 PiP doesn't work at all.

OK, I reflashed with latest OpenPLI 2.0 beta (also added latest drivers) and PiP works, also for HD + SD. PiP window can only be SD, because secondary video decoder (/dev/dvb/adapter0/video1) can only display SD content. video0 can display HD content concurrently. This is mentioned in Broadcom BCM4705 specs.

I don't know why it wasn't working on my previous image (I think I had OpenPLI-2.0-beta from 17/12/2010 and did online updates since then).

[OldDeuteronomy]

I might have found something that might help to pin down the root cause. I started another test recording, again manually via REC key, but this time I did not chose the first option that records the current show, but the 3rd one, which is to record infinite until manually stopped. And this recording is now working since more than 90 minutes, and the filesize also already exceeded the 4GB boundary without any problem.

I think that when using this method to record something, no timer is being used. So the issue MIGHT be that as soon as the recording is based on a timer (no matter if a programmed timer from EPG or the timer that is automatically being created when performing a manual record with the first menu option from the REC menu), it fails sooner or later, while a manual "infinite" record really works until it's being stopped manually.

I will leave this record for some more time to be sure, and will also perform more records from different channels the same way, but right now it really seems to be an issue with the timer handling.

edit: Forget what I've said. It looked good, but the recording stopped just a moment ago. The filesize at this point in time is 4.699.602.944 bytes. I will however perform more manual and infinite recordings to see what happens.

[swiffer]

4,6 Go ? FAT32 limitation ?

[metoo]

same here with vuduo and latest beta2 build

That´s interesting, I assume you are referring to the recording problems.

The issue is then no longer isolated to the ET9000.

Gr
JeDeJe

Yes, i refer to the recording problems.
it happens also with small recordings 30-45 minutes HD 1,8-2 GB and even wen i set an extra 30 minutes recordingtime.

i have writen it yesterday in dutch section to

[OldDeuteronomy]

I don't think that the HDD is being formatted with FAT32 when I format it in the box. So yes, it LOOKS like the FAT32 limitation, but no, it actually isn't. Besides, the problem itself has nothing to do with that anyway, because most recordings are interrupted long before the file reaches that size.

[OPERATION]

I have a WD20 2 Terabyte internal, same problem with recordings and timeshift.

90% of the files are to short/broken.

Sometimes, the recording/timeshift job is broken, the status display who shows the HD is recording, still blinks.

I re-formated my disk with different configurations, no luck.




sorry, my school englisch.... 30years ago

[MiLo]

To diagnose, could you run a recording while enigma2 is logging to the commandline. To do so, issue the commands:

init 4
enigma2

on a telnet (or ssh) session, and start a recording after that. When the recording breaks, copy the logging to a file and post it. Be sure to set the client's (e.g. putty) logging limit to "unlimited" or something to that extent, so that you can get all of it.

[OldDeuteronomy]

Will try that right away. My currently running test record by the way has now exceeded 5GB in size and still works. So definitely no 4GB boundary issue.

[swiffer]

I have a WD20 2 Terabyte internal, same problem with recordings and timeshift.
...

which image are you running ?