Re: Announcements < LiveTV changes: calls for testers

Post by **SnouF** » Fri Feb 28, 2014 9:35 pm

Hello,

I can not write response in the subject LiveTV changes: calls for testers se I create a new topic here

These changes correct bug #11949 ([some] rtsp streams doesn't work) ?

Post by **jyavenard** » Fri Feb 28, 2014 11:24 pm

No... If anything was broken there before, it still will be

Post by **SnouF** » Sat Mar 01, 2014 3:04 pm

Yes it was (and it'is also) broken impossible for me to use mythtv 0.27.

fphillips · Post by **fphillips** » Mon Mar 03, 2014 4:47 am

Hi JYA

I have been testing since Thursday. My first comment is that you should change the verbosity of the FILE_WRITTEN message (to VB_NETWORK?), as I get them on every logging mythfrontend every 10 secs for every video file being written, whether recording or livetv, displayed on the frontend or not.

I have a reproducible regression from fixes/0.27 (f1e620c). Start livetv near a program boundary and watch across that boundary for a minute or less, then change channels and watch. I did 3min-30sec-2min. At that point, you can't seek back through the chain in 027candidates (unless you are very persistent) but can with fixes/0.27. Logs (-v playback) are:
27candidates http://pastebin.com/sT3nKmwH
27fixes http://pastebin.com/700SsnH4

The other seek problem I have is probably an existing one, I just haven't found a way to reproduce it. What I call "still frame wonkiness", where seeking though the chain you hit a point where the osd says "Still Frame" and it jumps towards the far end of the program. Something akin to #11933.

I have tested the other things on your announcement. No crashes or anything to report.

Post by **jyavenard** » Mon Mar 03, 2014 8:57 am

fphillips wrote: I have a reproducible regression from fixes/0.27 (f1e620c). Start livetv near a program boundary and watch across that boundary for a minute or less, then change channels and watch. I did 3min-30sec-2min. At that point, you can't seek back through the chain in 027candidates (unless you are very persistent) but can with fixes/0.27. Logs (-v playback) are:
27candidates http://pastebin.com/sT3nKmwH
27fixes http://pastebin.com/700SsnH4

hello.

This is not a regression per say as you couln't rewind at all there before

Rewinding to an earlier program, would only ever rewind to 15s from the end of the second last program before.

However, I am aware of this issue. It's a racing condition whenever the ringbuffer starts buffering future data and reach the end of the recording.

You can actually rewind, but if you rewind again within 15s from the end of the program, then it will automatically jump to the next program.

So say you have program 1: 00:00 to 01:00
program 2 goes from 01:00 to 02:00

so if you are in program 2 at 01:03
press rewind, you will find yourself at program 1: 00:45

so far so good. Press rewind again, it will go to 00:35 and imediately jump to program 2 01:00

The way to get around it is either either press rewind (default 10s jump) very quickly to pass the 15s mark
Or rewind by a greater amount.
Like press 1 LEFT

which will rewind by 1 minute.

I believe #11933 has been fixed by those last changes...

Post by **jyavenard** » Tue Mar 04, 2014 12:01 pm

fphillips wrote:Hi JYA

I have been testing since Thursday. My first comment is that you should change the verbosity of the FILE_WRITTEN message (to VB_NETWORK?), as I get them on every logging mythfrontend every 10 secs for every video file being written, whether recording or livetv, displayed on the frontend or not.

done.

It's now only shown if you have network messages on.

I have a reproducible regression from fixes/0.27 (f1e620c). Start livetv near a program boundary and watch across that boundary for a minute or less, then change channels and watch. I did 3min-30sec-2min. At that point, you can't seek back through the chain in 027candidates (unless you are very persistent) but can with fixes/0.27. Logs (-v playback) are:
27candidates http://pastebin.com/sT3nKmwH
27fixes http://pastebin.com/700SsnH4

The other seek problem I have is probably an existing one, I just haven't found a way to reproduce it. What I call "still frame wonkiness", where seeking though the chain you hit a point where the osd says "Still Frame" and it jumps towards the far end of the program. Something akin to #11933.

I have tested the other things on your announcement. No crashes or anything to report.

Ok, I think I've nailed that one.

Seeking should now always work, even when done next to a program boundary...

Please give a try. Changes have been backported to devel/027candidates

MythTV Official Community Forum