747 replies to this topic

[greatred]

@BuGless
off course this is a workaround.
But how about cutting commercials on a PC instead of doing this directly on the box ....
Sound like a workaround to me ....

The thing is that a feature has been broken and now drivers are blamed.
It not like timeshift has been recently implemented - it was working prior to the changes from Dec 31st.
If we want to force VU+ to make the drivers better, users should not be forced to forget about a simple functionality like timeshift.
Blaming drivers can be relevant for SOLO2 users, but not for users of boxes where timeshift was working since ages.

Edited by greatred, 23 January 2013 - 11:21.

[BuGless]

@BuGless
off course this is a workaround.

Just trying to save the guy's marriage... :-)

The thing is that a feature has been broken and now drivers are blamed.

Blaming drivers can be relevant for SOLO2 users, but not for users of boxes where timeshift was working since ages.

Well, I think this needs to be put in perspective. I do not pretend to know everything about the driver API and/or timeshift implementation of engima2.
However... several remarks can be made:
- I have seen numerous references to timeshifting in places in enigma2 where they shouldn't have been. Meaning, the whole (historic) timeshift implementation looks to be a giant kludge held together by needle and thread to begin with.
- It is not uncommon that people do things wrong, but things still (sort of) work. I.e. in the case of drivers, if the driver is not built according to spec, but cuts corners here and there, then sadly, there are no guarantees that it *consistently* results in non-working functionality. In short, when then the method by which the driver is utilised changes, but is still according to spec, then (obviously) the drivers that were correct from the get-go will still work, and drivers that were broken from the start, will start to exhibit erratic behaviour.

So, it could be quite "normal" that faulty drivers can be blamed for a non-working timeshift, even if it has been working for ages already.

[ivos83]

Doest anyone have a copy of the older firmware(s)? If not, i will try to go back to the firmware of 01-11-2012 (Vu+ Duo) of which i have a copy.
If anyone would also like to have the 01-11-2012 firmware of the Duo, please contact me.

[SpaceRat]

Well, doesn't matter anymore. I just upgraded to VTI 5.0.
If Vu+ does drivers that crappy, I thought it might be better to use a distro based on their entire crappy image then ;->

Timeshift, HbbTV, Remote (Normal/Keyboard mode) and so on work so far and the EPG is reboot-persistent ... Now we'll just have to see if the stuttering/freezing video problem is fixed there too.

[SpaceRat]

@BuGless
off course this is a workaround.
But how about cutting commercials on a PC instead of doing this directly on the box ....
Sound like a workaround to me ....

I don't deem a sat receiver fit for this purpose. Why would I want to fiddle around with a remote control and block the sat receiver in the living room when I can use a mouse and much more computing power in the office for cutting videos instead?

What do I have a network for?

I would also guess that about nobody actually just cuts out commercials from recordings.
Recordings are a one time thing: Record, watch, delete. At least that's how everybody I know handles it.

Sounds kinda moronic to me to build up your personal video library from TV-recordings with the commercials cut out right on the box ...

But everybody I know who got his/her hands on a hdd receiver loves Timeshift instantly.

[betacentauri]

Hi,

today I have the same problem with my et9200. I think it wasn't there the last days
(image is from early january. PTS was installed but is now deinstalled since several days).

I do the following (log2.txt):
1. Press pause.
2. Wait 4-5 seconds
3. Unpause
4. Wait 30 seconds
5. Pressing 1 should rewind 15 seconds, but it switches to live tv.

In the other log I did another testing but with the same result.
Timeshift files are there!
You can see that there are "wait for driver eof timeout" log entries. Even after unpause.
I think they should not appear.
And after pressing 1 the log shows this:

wait for driver eof timeout
wait for driver eof timeout
action: seekdef:1
eDVBServicePlay::seekRelative: jump -1, 1350000
seek.
eFilePushThread stopping thread
wait for driver eof aborted by signal
FILEPUSH THREAD STOP
thread joined 0
AUDIO_CLEAR_BUFFER - ok
VIDEO_CLEAR_BUFFER - ok
setIoPrio best-effort level 0 ok
FILEPUSH THREAD START
samples step 41942988, pts begin 3827507231, pts end 3830858831, offs begin 2288, offs end 17133568:
eDVBTSTools::getPTS got it from sc file offset=2288 pts=3827507231
adding sample 2288: pts 0 -> pos 2288 (diff 0 bytes)
using: 0:3351600 -> 2288:17133568
eDVBTSTools::getPTS got it from sc file offset=7692240 pts=3829188431
adding sample 7693712: pts 1681200 -> pos 7692240 (diff -1472 bytes)
calculated diff 1960 ms
diff to big, refining
using: 0:1681200 -> 2288:7692240
No PTS, try next
eDVBTSTools::getPTS got it from sc file offset=6919936 pts=3829026431
adding sample 6885312: pts 1519200 -> pos 6919936 (diff 34624 bytes)
calculated diff 160 ms
aborting. Taking 6885312 as offset for 1519200
ok, resolved skip (rel: 1, diff 1519200), now at 00690fc0
eDVBChannel: End of file!
timeshift EOF, so let's go live
SwitchToLive
eFilePushThread stopping thread
FILEPUSH THREAD STOP

Perhaps it's an initialization problem. When I pause more than 20 seconds and then press 3 timeshift works without problems(also seeking back with 1). Perhaps the file length (duration) calculation is wrong in special situations. A reboot didn't solve the problem.

Attached Files

•  log1.txt   35.27KB   0 downloads
•  log2.txt   35.14KB   0 downloads

Edited by betacentauri, 23 January 2013 - 21:17.

[SpaceRat]

Blame X-Trend, must be crappy drivers or a crappy phase of the moon. And it's more important that the box works as cutting machine.

Who uses a sat receiver as sat receiver anyways?
*g*

[littlesat]

Get more then 30 seconds and it will not go to live tv.... Seems you need a bigger buffer.
Please note in e2 timeshift was always a p.i.t.a.

Edited by littlesat, 23 January 2013 - 23:25.

[betacentauri]

Hi littlesat,

thanks for the answer!
I'll test it. But I don't believe that that will help. What is curious is, that I could swear that this problem was not there
last week (and I'm using timeshift almost every time I watch TV) and I did no update.
Isn't it unnormal that the log message "wait for driver eof timeout" is there even when I unpause?

[littlesat]

I have also this fast go to live issue here when there is not much timeshift buffered yet. I think it was like this for a long time... Especially with skip back it can go through the begin of the file... and I think this is covered the same as an eof...
The wait for driver eof timeout is not an issue... this is normal.

At this moment I'm thinking about completely remove the timeshift functions in cpp of e2... that will clean a lot of stuff in the code... and from python start an instant recording instead (e.g. in the .Trash directory for auto delete...and you have the recordings always available) - and arrange a special playerBar for the timeshift. But this requires a lot of rework... alias time... alias plugins as PTS will do nothing at all anymore...

Edited by littlesat, 24 January 2013 - 07:58.

[pieterg]

this is probably caused by recent changes in the ts timekeeping.
e2 thinks it's near the end-of-file point, and switches to live.

[betacentauri]

I think yesterday I did also this test:
1. Press pause.
2. Wait 4-5 seconds
3. Unpause
4. Wait 80 seconds
5. Pressing 4 should rewind 60 seconds, but it switches to live tv.
(I will test it again this evening)

So in this case e2 shouldn't think that it's near end-of-file.
@littlesat: You made changes in the tstools.cpp (it was already discussed here in the thread). Can't it be that the length or pts calculation now behaves in a different way? So we should look, if there goes something wrong.

[pieterg]

5. Pressing 4 should rewind 60 seconds, but it switches to live tv.

So in this case e2 shouldn't think that it's near end-of-file.

well, it depends on how e2 calculates where to jump to.
If the calculation is wrong, it might still end up at the end of the file.

[betacentauri]

I have retested this:
1. Press pause.
2. Wait 4-5 seconds
3. Unpause
4. Wait 80 seconds
5. Pressing 4 should rewind 60 seconds
But e2 switches to live tv.

But rewinding works if you pause more than 15 seconds:
1. Press pause
2. Wait 17 seconds
3. Unpause
4. Wait 30 seconds
5. Pressing 1
-> e2 rewinds 15 seconds.

Well, you're the experts. You most probably can find the wrong calculation much quicker than me.
If you have no time, I'll try to find it.

[littlesat]

For back jumps I thought i jumped back some random value... and then play forward again to get the good point.... As reverse is difficult... So it can step to far back reaching the begin what is seen as an end... But please notify as this is somehow RANDOM..... it depends on the step back it tries first...
indeed the new timing stuff that fixes other painfull issues could be related.... ...

I went last weekend throught the complete timeshift code and consider it as being very bas written code.... very sensitive to good fixes anywhere...

Edited by littlesat, 24 January 2013 - 18:53.

[betacentauri]

At this moment I'm thinking about completely remove the timeshift functions in cpp of e2... that will clean a lot of stuff in the code... and from python start an instant recording instead (e.g. in the .Trash directory for auto delete...and you have the recordings always available) - and arrange a special playerBar for the timeshift. But this requires a lot of rework... alias time... alias plugins as PTS will do nothing at all anymore...

I would also start a recording but in c++ part. The user won't see live tv, he always sees the recording (this avoids the
damn switching between live tv and recorded file). So a real permanent timeshift. Problem would be how to use
1,3,4,6,7,9 keys for seeking and zapping at the same time. And a ringbuffer (e.g. 3 hours) would be great. Otherwise
the timeshift file would get really big if you don't zap. But saving the buffer when the user requests it would be then a
problem....

[littlesat]

Our harddisks are so big the current days.... Do why do we really need a ring buffer or slice buffer?

Edited by littlesat, 24 January 2013 - 19:13.

[SpaceRat]

Afaik ring buffers are a pain in the *ss on any Lunix compatible file-system.

And why use 1 .. 9 for seeking anyways? It's kinda work-around and not the way it SHOULD work (There are buttons for seeking already ...)

[betacentauri]

For back jumps I thought i jumped back some random value... and then play forward again to get the good point.... As reverse is difficult... So it can step to far back reaching the begin what is seen as an end... But please notify as this is somehow RANDOM..... it depends on the step back it tries first...
indeed the new timing stuff that fixes other painfull issues could be related.... ...

I went last weekend throught the complete timeshift code and consider it as being very bas written code.... very sensitive to good fixes anywhere...

Mhmm. I don't think that the jump back is the problem. Because the problem is still there when I wait 1-2 minutes
after unpause. So the step back can't reach begin of file. Or do you jump back several minutes when you only want to
jump back 15 seconds?

I agree that it would be very difficult to reinvent timeshift. It would take several weeks/month and you can only publish it intirely, because otherwise all people would have problems with normal timeshift and with the timeshift plugins.

Our harddisks are so big the current days.... Do why do we really need a ring buffer or slice buffer?

Well, you're right. This is not so important.

Edited by betacentauri, 24 January 2013 - 19:23.

[betacentauri]

Afaik ring buffers are a pain in the *ss on any Lunix compatible file-system.

And why use 1 .. 9 for seeking anyways? It's kinda work-around and not the way it SHOULD work (There are buttons for seeking already ...)

Yeah, also it's not possible to delete the first bytes of a file without copying the whole file....

I don't need to use the 1,3 .. keys to seek, but everybody uses them and it would be difficult to change it without riot. On my old topfield stb was a nice binary search, which was really quite good.