Click here to go to the forum index Click here for the home page
 
Author Message

<  Bugs  ~  Recorded BBC1 programme switching to itv4 and back!

Page 5 of 7
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
R2-D2
Posted: Tue Jan 15, 2008 9:57 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
bdb wrote:
- what are the recording 'slots'?
- it claims to have shifted the timeshift to slot 1
but has not adjusted the hardware (and that would causes an interruption)
There are high-level (firmware) recording "slots" (that's what I call them). There are two of these and they can be set to any of the two low-level recording "paths" (PathA and PathB). So a recording could actually be on "slot0" and "path1" (although I'd call that PathB). The remaining path (PathC) is a non-recording one, but can be used to provide the TV output (so it ought to be used for PiP or playback, where possible). The "paths" are connected to a tuner, CAM or disk output.

The problem happens because the system likes to be as free as possible in dishing out paths, so it gives the PiP one of the recording paths (Path A or B, depending on which the timeshift isn't using). This means the PiP is more often available, but then the firmware doesn't take this into account when trying to start the recording. One of PiP and timeshift must die because there is (I think) no high-level way to change the PiP to the non-recording PathC (the new recording and timeshift can't go to PathC because it can't record). One high-level solution would be to close PiP, start recording then open PiP again. It's tricky to make that into a patch. Smile Simple (patchable) solutions would be to close PiP or stop timeshift.
View user's profile Send private message Visit poster's website
MikeyP
Posted: Tue Jan 15, 2008 9:58 am Reply with quote
Frequent contributor Joined: 17 Jan 2006 Posts: 4816
glad you've seen the light (fault) now Wink

_________________
www.mpavservice.co.uk
www.mpavservice.co.uk
www.mpavservice.co.uk
Parts or Repair service for your poorly toppy/PSU - 'talk to me' Smile my name's Mike though, not Terry Tibbs Very Happy
View user's profile Send private message Visit poster's website
nwhitfield
Posted: Tue Jan 15, 2008 10:03 am Reply with quote
Site Admin Joined: 20 Mar 2005 Posts: 9520 Location: London
So you can reproduce it with the newer tuners, R2? I don't need to get them to dig around just for stuff related to the older ones then...

_________________
Support this site - make a donation to our running costs
View user's profile Send private message Visit poster's website
R2-D2
Posted: Tue Jan 15, 2008 10:08 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
nwhitfield wrote:
So you can reproduce it with the newer tuners, R2? I don't need to get them to dig around just for stuff related to the older ones then...
No, it's timeshift that's the critical thing, meaning that the timer recording starting is actually a second recording (and second recordings are what cause the problem all over the place).
View user's profile Send private message Visit poster's website
MikeyP
Posted: Tue Jan 15, 2008 10:15 am Reply with quote
Frequent contributor Joined: 17 Jan 2006 Posts: 4816
I can't see in whatever change they must have done to the tuner handling code would eradicate this problem unless they used a completely new rewritten module ?

If R2 can now reproduce the fault after he's turned on the buffer and he does have the new tuners, the fault must still be in both versions code?

Surely toppy can sort the code , the fault is easy to replicate. I don't use PIP as a result of the chance of it mucking up recordngs

_________________
www.mpavservice.co.uk
www.mpavservice.co.uk
www.mpavservice.co.uk
Parts or Repair service for your poorly toppy/PSU - 'talk to me' Smile my name's Mike though, not Terry Tibbs Very Happy
View user's profile Send private message Visit poster's website
bdb
Posted: Tue Jan 15, 2008 8:18 pm Reply with quote
Frequent contributor Joined: 18 Oct 2005 Posts: 499
R2-D2 wrote:
There are high-level (firmware) recording "slots" (that's what I call them). There are two of these and they can be set to any of the two low-level recording "paths" (PathA and PathB).

- that's not quite how I'd interpreted things;

the hardware seems to have:
3 paths: {A,B,C}
4 sources: {T0, T1, PlyBck, CAM}
4 destinations: {MPEG (main+sub), Recording (Slot0, 1), PID Filter (x lots), CAM}
- why is path C 'non-recording'? this does not appear to be a hardware limitation.

So all these should be possible:
Code:
T0 :-> pathA
T1 :-> pathB
playback :-> pathC   
cam: not used
pathA :-> mpeg      [main T0]
pathA :-> mpeg      [sub T0]
pathA :-> rec slot0 [timeshift T0]
pathC :-> rec slot1 [record(copy) file]
pathB :-> pid       [process T1 in s/w, e.g. epg/mheg]

T0 :-> pathC
T1 :-> pathA
playback :-> pathB
cam: not used
pathC :-> mpeg      [main T0]
pathB :-> mpeg      [sub PlyBck]
pathC :-> rec slot0 [record T0]
pathA :-> rec slot1 [record T1]
pathC :-> pid       [process T0 in s/w, e.g. epg/mheg]

T0 :-> pathC
T1 :-> pathA
plybck: not used
CAM :-> pathB
pathC :-> cam       [T0]
pathB :-> mpeg      [main T0 via cam]
pathA :-> mpeg      [sub T1]
pathC :-> rec slot0 [record Cam (e.g. encrypted)]
pathB :-> rec slot1 [record T0 (unencrypted)]
pathC :-> pid       [process T0 in s/w, e.g. epg/mheg]

It would appear to me to be a software flaw rather a hardware limitation - however fixing it by patching may not be trivial ...

- another manifestation of this (or a related) bug is when using the api call TAP_Channnel_Start(). It generally fails to operate correctly on the sub window, especially if the main/sub channels are the same.

bdb
View user's profile Send private message
R2-D2
Posted: Tue Jan 15, 2008 8:53 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
bdb wrote:
- why is path C 'non-recording'? this does not appear to be a hardware limitation.
You could easily be right -- I'm only working from the firmware code so it might just be a choice they've made since there appear to only be two hardware recording slots. PathC seems to be treated everywhere as a special case, with no recording attributed to it. For example, if playback is on PathC then it is not dumped when a second recording starts (you can check this without the Xp patch by starting playback just before a short recording ends then continue watching while two later timers fire).

If you can connect PathC to one of the two hardware recording slots (or if you've found a third slot!) then they've missed a trick. But, of course, most of the low-level code is from Nec... Do you know what the Humax does?
View user's profile Send private message Visit poster's website
R2-D2
Posted: Tue Jan 15, 2008 10:39 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
nwhitfield wrote:
Preventing PiP during playback, eh? Sounds familiar!
I have only just understood that reference. Smile
View user's profile Send private message Visit poster's website
bdb
Posted: Tue Jan 15, 2008 11:31 pm Reply with quote
Frequent contributor Joined: 18 Oct 2005 Posts: 499
just had a related but different bug ...

recording bbc1 (22:35-23:15), ch4(22:00-23:00)

started watching bbc1 on ~ 10 minutes lag
ok for ages
@23:00 recording for ch4 finished
@23:10 bbc1 suddenly jumped to live (it had reached the end of the file)
bbc1 appeared to still be recording, but seems to have stopped receiving any more data. the recording is only ~35 mins long, even though it was recording for ~50 minutes (bbc1 was running late, and the 'accurate recording' sort of successfully kicked in - it extended the recording, pity it wasn't recording anything...)

when the ch4 recording finished it probably swapped the tuners around, causing the final part to be recorded from the wrong tuner [and hence 0B].

bdb
View user's profile Send private message
R2-D2
Posted: Wed Jan 16, 2008 7:51 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
bdb wrote:
just had a related but different bug ...
You mentioned AR, so what firmware are you using? Is the bug reproducible? I'm guessing you still have Timeshift enabled, but it probably wasn't activated when the Ch4 recording finished since you were recording the current channel.
View user's profile Send private message Visit poster's website
R2-D2
Posted: Thu Jan 17, 2008 9:35 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
Cancelling timeshift in order to record the right thing is a one byte change. Smile But I think the problem is specific to the main channel being on the same mux as the new recording (or else the CYR code would kick in and close the PiP). The path selection code seems both too trivial and far too complex (Neutral) so the real bug lies there I think.
View user's profile Send private message Visit poster's website
R2-D2
Posted: Fri Jan 18, 2008 2:21 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
This is a very interesting bug. The code appears to do exactly the right thing (even does the PiP close then open again, that I suggested above!). But clearly it doesn't end up that way. More analysis needed, but in the meantime is this bug bothering anyone enough to warrant a patch that forces the timeshift to be stopped?
View user's profile Send private message Visit poster's website
mike.hinson
Posted: Fri Jan 18, 2008 2:35 pm Reply with quote
Frequent contributor Joined: 18 Nov 2005 Posts: 1735 Location: Bordon, Hants UK
If the choices are
1). Kill the timeshift buffer
2). Record the wrong thing or perhaps make an invalid recording

then 1 has to be less bad....

I have never run foul of this bug myself but it is quite nasty for people who make a lot of use of the PiP feature.

The desired outcome is for it to do everything without problems but spending a lot of time trying to fix this & only exchanging it for a mild bug (1 above) might mean that you time is better spent elswhere until more options become obvious to you.

/\/\
View user's profile Send private message
R2-D2
Posted: Fri Jan 18, 2008 10:36 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
Almost forgot to post the patch! Smile [Tc] RecCancelTS cancels timeshift when looking for a recording slot. People who use timeshift are not going to like it very much... and people who don't use timeshift won't care. But at least the recordings ought to work. (Still trying to track down the cause of the bug.)
View user's profile Send private message Visit poster's website
R2-D2
Posted: Sat Jan 19, 2008 1:04 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12149
Oh dear -- it's a right mess. First off, I think the intention might actually have been to stop timeshift in this case, if the system had picked the "correct" path.

The first problem is that, while the code does the "turn off PiP, set path, turn PiP back on" it (unfortunately) does this without actually marking the new recording slot (temporarily) as active so the PiP is just restarted back on the path it had been on (rather than moving to PathC), so the whole process is a big fat NOP. DOH! But it's actually a bad NOP because it was meant to be freeing up that path, which has been selected for the recording -- end result: broken recording. (Ironically, there's a better process in there for dealing with stopping and restarting the main service, which leaves the restart to much later, and therefore has a better chance of actually working!)

Second problem is that, in this case, the code probably shouldn't be picking the PiP path: the timeshift path could actually reused (since it's on the right tuner). Earlier code (when starting a timer) does all sorts of checks to see what can be reused or turned off. One of those is turning off timeshift if the recording is going to be on the same channel. However, if the later code does end up choosing the same path as timeshift then this code will turn it off. So timeshift is doomed, and for no good reason.

But I think there's no real harm in the system not reusing the timeshift path, so the next tests will be whether that can be made to work.
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT
Page 5 of 7
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum