Here you go. The recording interrupted at around 15:03. At this point in time, nothing special happened in the putty output. What you see approx. 2 minutes later is when I went into the filelist, checked filesize, and then stopped the record. After this, the time stamp of the recording that I continously checked via FTP was updated to 15:06, but as said, it stopped to "grow" at 15:03.To diagnose, could you run a recording while enigma2 is logging to the commandline.
146 replies to this topic
Re: Clarketech ET9000 common bug thread #41
Posted 27 December 2010 - 15:12
Re: Clarketech ET9000 common bug thread #42
Re: Clarketech ET9000 common bug thread #43
Posted 27 December 2010 - 16:07
Created another log, just to be sure, but looks pretty much the same. Checked again continously the filesize via FTP. File stopped to increase at 15:41. I waited a bit longer this time (5 minutes) before I stopped the recording. The file's timestamp was again updated to the time I stopped the record, but the filesize did of course not change, and when viewing the record, it indeen interrupted at 15:41. At 15:41, nothing special in the log.
What now worries me a bit: When googling around, I found that some VU+ owners reported this issue already some weeks ago (maybe not here, but for instance in the VTI forum). Problem looks quite similar, and there is no solution yet. However, I did never had this issue with my VU+. OK, I never used the VTI image though, I was using OpenPLi on the VU+ for a long time now. For the VTI image, the problem started with VTI 2.0 (or 2.2?), which was released some weeks ago. Could it be that some sort of change that was introduced in VTI image a while ago has now been introduced to OpenPLI, causing the same issue?
Anyway, the fact that this issue seems to be existing on the VU+ for quite a while now without a solution being available, I'm asking myself if it wouldn't be better to stick to my VU+, which works perfectly fine with OpenPLi (at least 1.0, never tried 2.0). Not being able to properly record things is a k.o. criteria...
What now worries me a bit: When googling around, I found that some VU+ owners reported this issue already some weeks ago (maybe not here, but for instance in the VTI forum). Problem looks quite similar, and there is no solution yet. However, I did never had this issue with my VU+. OK, I never used the VTI image though, I was using OpenPLi on the VU+ for a long time now. For the VTI image, the problem started with VTI 2.0 (or 2.2?), which was released some weeks ago. Could it be that some sort of change that was introduced in VTI image a while ago has now been introduced to OpenPLI, causing the same issue?
Anyway, the fact that this issue seems to be existing on the VU+ for quite a while now without a solution being available, I'm asking myself if it wouldn't be better to stick to my VU+, which works perfectly fine with OpenPLi (at least 1.0, never tried 2.0). Not being able to properly record things is a k.o. criteria...
Attached Files
Re: Clarketech ET9000 common bug thread #44
Re: Clarketech ET9000 common bug thread #45
Posted 27 December 2010 - 16:49
Currently I have installed the latest "official" built from et-view.com, which is an OE1.0 build from 20/11. I am just performing a record of BBC HD. If that works (or also if it doesn't) I will update to the build from 15/12. Would need to do that anyway because in the 20/11 build, neither the SoftcamSetup plugin nor the usb2serial driver can be installed (installation starts, but the box hangs then), so no chance to use my smartcards.
If the 15/12 build is really the solution, I could of course live with it as long as it's necessary. However, there were other folks here reporting that they have this issue also with 1.0. I had it myself with 1.0. But it was the build from 17/12, so hopefully the earlier one is a go.
If the 15/12 build is really the solution, I could of course live with it as long as it's necessary. However, there were other folks here reporting that they have this issue also with 1.0. I had it myself with 1.0. But it was the build from 17/12, so hopefully the earlier one is a go.
Re: Clarketech ET9000 common bug thread #46
Re: Clarketech ET9000 common bug thread #47
Posted 27 December 2010 - 17:02
There's no mention of anything going wrong, it thinks it's still recording even though no data is coming out of the mux. Looks like the demuxer just stops outputting data at some point. Seems a driver issue, but could be related to the descrambler as well. Did you try with a FTA channel?
Real musicians never die - they just decompose
Re: Clarketech ET9000 common bug thread #48
Posted 27 December 2010 - 17:49
Yes I did. As said above, I just tested under the build that is downloadable from et-view.com (dated 20/11), and I recorded from BBC HD (FTA). Recording interrupted after approx 30 minutes at approx 1.3GB filesize.
I will now finally perform a test with the OE1.0 build from 15/12 that Jbg is using. However, I am afraid that the issue will be present here as well and that he just did not yet realized it. Because if you just look into the list of recordings, everything looks fine at first sight.
I will now finally perform a test with the OE1.0 build from 15/12 that Jbg is using. However, I am afraid that the issue will be present here as well and that he just did not yet realized it. Because if you just look into the list of recordings, everything looks fine at first sight.
Re: Clarketech ET9000 common bug thread #49
Posted 27 December 2010 - 17:57
Unfortunatly I have to confirm this problem. Several recordings on FTA und other channels are incomplete. All records start at the correct time and stop after several minutes. From 7 minutes up to 75 minutes but all incomplete (8 recordings). Records are done on OpenPli 1.0 from 15/12/2010. This is a big issue which should be solved soon.
Br,
Jbg
Br,
Jbg
Re: Clarketech ET9000 common bug thread #50
Re: Clarketech ET9000 common bug thread #51
Re: Clarketech ET9000 common bug thread #52
Re: Clarketech ET9000 common bug thread #53
Posted 27 December 2010 - 18:32
This should be a driver issue. Unfortunately can't check it with internal HDD, but I'll test long recording with external NAS mounted with NFS.
Is your scheduled recording uses tuner A or tuner B? Does it make any difference on the issue? Do you zap while box is recording?
Does recording demux buffer size makes any difference?
Is your scheduled recording uses tuner A or tuner B? Does it make any difference on the issue? Do you zap while box is recording?
Does recording demux buffer size makes any difference?
Re: Clarketech ET9000 common bug thread #54
Posted 27 December 2010 - 18:33
Can't make that test today, or my wife kills me.If the original image also do not record correct, it is a reason for me to send back the box.
Please let me know OD.
If anyone else would want to do that test, I could upload the factory-installed image in case you don't have it. Just let me know.
Else I would try it tomorrow.
It would of course be great if CT would answer to this big issue fast. I'm quite sure the PLi team already forwarded this issue to the appropriate folks.
Re: Clarketech ET9000 common bug thread #55
Re: Clarketech ET9000 common bug thread #56
Posted 27 December 2010 - 19:30
Tuner A for me. The only thing I do, is to insert an USB key to watch another film during the record of the incredible.
In fact, at the present time my both receiver are connected.
So, tonight, Dr Who & Wild Hogs are scheduled, and I will do nothing on it.
Recording demux size was previously set to 1,5 Mbytes, I set it to 2Mbytes to see.
In fact, at the present time my both receiver are connected.
So, tonight, Dr Who & Wild Hogs are scheduled, and I will do nothing on it.
Recording demux size was previously set to 1,5 Mbytes, I set it to 2Mbytes to see.
Re: Clarketech ET9000 common bug thread #57
Re: Clarketech ET9000 common bug thread #58
Re: Clarketech ET9000 common bug thread #59
Posted 27 December 2010 - 20:20
Another info regarding the recording issue: I already reported in another thread few days ago that I'm using a media player to stream channels from the box to the player. This perfectly worked with the VU+, but with the ET9000, the stream interrupts from time to time. I now found out that the interruptions of the streams and the recordings are exactly identical. That means that when I'm recording a service and watch the same service simultaneously on the media player, the stream interrupts at the very same moment the recording stops.
Re: Clarketech ET9000 common bug thread #60
Also tagged with one or more of these keywords: ET9000
OpenPLI auf et9000 mit crashlog bei rebootStarted by manyone, 8 Dec 2019 et9000 |
|
|||
ET9000 with SSD crashesStarted by erwin288, 26 Jan 2019 ET9000, SSD, Xtrend, crash |
|
|||
Sundtek USB Kabel tuner ET9000Started by KBDE, 23 Jan 2019 sundtek, cablescan, ET9000 |
|
|||
Geluid stopt bij afspelen MKV ET9000Started by jbnl, 24 Nov 2018 mkv, et9000, geluid |
|
|||
Xbox One USB tuner op de ET9000Started by jbnl, 4 Sep 2017 usb, xtrend, et9000, tuner |
|
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users