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

<  Bugs  ~  "Check Your Reservation" -- request for help

Page 4 of 25
Goto page Previous  1, 2, 3, 4, 5 ... 23, 24, 25  Next
tichtich
Posted: Fri Nov 23, 2007 3:08 pm Reply with quote
Frequent contributor Joined: 08 May 2005 Posts: 1389 Location: Eastbourne, UK
Sorry if you've mentioned this before, but are you only looking at CYRs, or are you also looking at cancellations of playback which are not accompanied by a CYR?

I haven't had a CYR for a very long time, but I frequently have cancellations of playback without a CYR (when a second recording starts during playback). FWIW almost all my viewing is playback of recordings (rarely live or chase play), and I normally keep my Toppy tuned to channel 100 (which, with MHEG disabled, is a blank screen).

_________________
Richard Wein
Firmware: 5.13.65 (patched). Auto Start TAPs: TapCommander 1.0.2, Power Down 0.6, DescriptionExtender 2.2, mei2archive 3.8I3, Automove 1.8, QuickJump 1.54, Improbox 2.1RC8, Jag's EPG 3.0b3 (TV & radio), Media Manager 1.5, MHEG Control A2g, Extend 1.7. PC apps: DGtoTop 1.1. Profile last updated 13/05/2009
View user's profile Send private message
Andy K
Posted: Fri Nov 23, 2007 3:18 pm Reply with quote
Frequent contributor Joined: 14 Jun 2005 Posts: 3520
keep up the good work. If you could fix or improve this one you would be a bigger star than you already are.

_________________
Autostart TAPs: Jags 3, Bookmark 2uk, Quickjump 1.71, Power Manager 1.1, Description Extender 1.5/2.1, MEI2Archive 3.8l6, Tap Launcher 3.5a, Tap Commander, AccurateBMExtend 0.3, RemoteExt 1.5, TunerRecAR.2
Launched during EPG scan: Crid, SeriesLink 0.35
TF5800 Version 5.13.65 PHT2UFXp5Xw3RpPcE2Bf2BqRsRh3Pf1Ec2ErEfHe1 Ra3Cf2Ct
Samsung 400Gb+Fan
View user's profile Send private message
nwhitfield
Posted: Fri Nov 23, 2007 6:45 pm Reply with quote
Site Admin Joined: 20 Mar 2005 Posts: 9579
I hope the code you were going to add for case 2 isn't an abandoned runt of their last time, which just make the wretched thing mess up recordings Wink

_________________
Support this site - make a donation to our running costs
View user's profile Send private message Visit poster's website
R2-D2
Posted: Fri Nov 23, 2007 7:26 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
nwhitfield wrote:
I hope the code you were going to add for case 2 isn't an abandoned runt of their last time, which just make the wretched thing mess up recordings Wink
Could well be. Smile First attempt still gave stopped playback Confused and seemed to have gone back to the original mux so I ended up with a 0Mb file for one of the recordings -- most likely due to StartChannel()s in there. However, I know that it's possible to change the mux while playback is happening because I've managed to do that by poking about. It's just the CYR code that's a mess, not the concept.
View user's profile Send private message Visit poster's website
R2-D2
Posted: Mon Nov 26, 2007 11:54 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
OK, a small update: there was a second StopTS() in a more basic routine, so that got eliminated. But I was still getting stopped playback. I tried fiddling around behind the scenes to help the patch, and that seemed to work. Confused And the I realised why: the first test was starting two recordings (1 minute apart) during the same playback. When I was fiddling behind the scenes I had stopped the playback after the first timer and then restarted it again. Tried this technique with just the patch and it worked fine! Recording on Ch3, watching Ch5, start playback, recording starts on Ch1 with no CYR and no interruption. Stop playback and I get dropped to Ch3, which I guess is the closest channel that was displayable (it would have been trying to go to Ch5 since I've not patched the channel bit).

So, more effort needed. The two recordings starting one after another is a subtlety I missed, so it's going to take some more staring at to see why that's different. I got a clue when I tried fiddling behind the scenes on a similar setup: the first recording got cut off at the point I changed the tuner's TP, so I suspect the (modified) code makes the first recording pick up the same (main) tuner as the second, which clearly won't work.

This is the hard case in terms of understanding what exactly needs changing, I think. The other two cases are easy in that regard, but difficult to see how to test for them.
View user's profile Send private message Visit poster's website
Tolksee
Posted: Mon Nov 26, 2007 11:58 am Reply with quote
Frequent contributor Joined: 12 Jul 2007 Posts: 169 Location: Wokingham, Berkshire
Looks like some very promising progress anyway. Cool

_________________
TF5800 Black Panther
MS Recommended Firmware + R0Wf
View user's profile Send private message
Black Cloud
Posted: Mon Nov 26, 2007 2:45 pm Reply with quote
Frequent contributor Joined: 18 Sep 2005 Posts: 300
Just to encourage you, you will make everyone in our household very happy indeed when you fix this.

Edit: Might even change my logon to Silver Lining Very Happy

_________________
HW: TF5800 Black Panther 1.5TB. FW: 5.13.65 Patched
SW: TAP Commander 1.32, Goldfish 0.5, Font Manager 1.0d, SecCache v0.4, EIT Sub v0.6, EPG2MEI v0.96, Extend v1.7, TF5000 Display v1.53, MyStuff 6.4, MHEG On/Off A3, WSSkiller V2.12d
View user's profile Send private message
R2-D2
Posted: Mon Dec 10, 2007 9:45 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
I had some more time to fiddle with this. I'm trying to make a TAP to help analyse what's going on at the lower-level (based on FireBird's findings) and it's coming up with some strange results. I'd eliminated the explicit playback stopping calls but I was still getting playback being replaced by live video when the second recording tries to start. And it dumps to the wrong live channel (the original one) even though the second recording thinks it's changed the channel to the right one. So a 0Mb file follows...

The interesting thing about the tests, though, is that PathA seems to be used for the Main Video in the normal use, and this includes playback. However, for chase play the setup seems to change to using PathC for the playback part (and hence the Main Video), with PathA being used for the recording part. And then, after the CYR happens, the Main Video gets changed to PathB (as might be expected) -- i.e. Main Video is interrupted to show the new recording channel. But this is the only time in my logs that I get PathB for the Main Video.

I was thinking that somehow the Paths are inflexibly linked to the output, but the results don't bear this out. It's just the system seems reluctant to change their usage automatically. More analysis needed, I'm afraid.
View user's profile Send private message Visit poster's website
humphrey1
Posted: Mon Dec 10, 2007 12:26 pm Reply with quote
Frequent contributor Joined: 25 Feb 2006 Posts: 205 Location: Hannington
R2-D2, I can't pretend to follow all your explanations, but I enjoy reading them and wish you all the best with your continual striving to improve the Toppy yet further.

Keep up the good, nay great, work!

_________________
TF5800, IA On, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Xl+B2BmCfCtEvEzIKeMPePfPsRtTaUUuUxVbVyWfWs
TAPs: Control Lock V1.1; EIT Sub (Game) v0.6; EPG2MEI v0.96; Extend v1.7; Font Manager 1.0d; MyInfo B5.6; QuickJump 1.72; MyStuff 6.4; SecCache (UK) v0.4; Surfer v0.14; TF5000 Display v1.43; TSSaver v0.5;
Sig generated by MyInfo on 17/1/13
?
View user's profile Send private message
R2-D2
Posted: Mon Dec 10, 2007 12:36 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
humphrey1 wrote:
I can't pretend to follow all your explanations
Sorry about the techy stuff -- it helps me keep track of progress and maybe it'll ring some bells with someone else who has looked at this stuff.

Latest enhanced TAP shows something very strange indeed: when the (failed) second recording starts (and stops playback), the Transponder info for the main tuner is thoroughly corrupt, showing both the wrong ChNum (same as the original viewed service, which it ended up on) and wrong TSID (same as sub). I hope this is a clue...
View user's profile Send private message Visit poster's website
humphrey1
Posted: Mon Dec 10, 2007 12:42 pm Reply with quote
Frequent contributor Joined: 25 Feb 2006 Posts: 205 Location: Hannington
R2-D2 wrote:
humphrey1 wrote:
I can't pretend to follow all your explanations
Sorry about the techy stuff -- it helps me keep track of progress and maybe it'll ring some bells with someone else who has looked at this stuff.
Don't apologise; I'm more than happy to try and broaden my understanding, and recognise that there are others (including yourself, of course) to whom your posts may be invaluable.

_________________
TF5800, IA On, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Xl+B2BmCfCtEvEzIKeMPePfPsRtTaUUuUxVbVyWfWs
TAPs: Control Lock V1.1; EIT Sub (Game) v0.6; EPG2MEI v0.96; Extend v1.7; Font Manager 1.0d; MyInfo B5.6; QuickJump 1.72; MyStuff 6.4; SecCache (UK) v0.4; Surfer v0.14; TF5000 Display v1.43; TSSaver v0.5;
Sig generated by MyInfo on 17/1/13
?
View user's profile Send private message
R2-D2
Posted: Mon Dec 10, 2007 5:59 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
More variations on a theme: if I change the channel manually to the correct one for the 2nd recording after being dropped to live TV on the wrong channel (because of my current "fix" patch), then the second recording starts getting data in it (from that point).

If I change the tuner TP manually before the 2nd recording starts then it makes no difference unless I also change the system's record of the current main TV service (which is a small clue, I think) -- but even then the playback is still replaced by live TV (the difference is that the 2nd recording becomes valid).

If I manually stop the playback after the 1st recording starts and restart it again before the 2nd recording fires then there is no interruption (just like when the 1st recording starts)... and the only (logged) thing that has changed is that the system has mysteriously decided this time to put the playback on PathC, rather than PathA where it was (and normally is during these non-chaseplay tests). I'm now curious as to whether I can force playback to always use PathC (there seems little danger in doing this, but it's going to be hard to find...).
View user's profile Send private message Visit poster's website
PeteY
Posted: Tue Dec 11, 2007 3:43 am Reply with quote
Frequent contributor Joined: 08 Dec 2006 Posts: 164 Location: Lombardy, Italy
R2-D2 wrote:
I'm now curious as to whether I can force playback to always use PathC....


Would this mean that playback would never be interrupted? That would be cool.

_________________
Toppy: TF5800PVR 250GB Firmware: 1365 Patched
No TAPs ATM
View user's profile Send private message
R2-D2
Posted: Tue Dec 11, 2007 8:58 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
PeteY wrote:
Would this mean that playback would never be interrupted? That would be cool.
That's the hope in this particular case.

I believe I now understand what's happening, and why Topfield might say the fix would require a big change. There are three internal "paths" (A, B and C). Each one of these can be connected to one of four inputs: the two tuners (live TV), the hard disk (playback) and the CAM (encrypted stuff). These paths can then be connected to outputs: Main and PiP video (watching) and the hard disk (recording). Except only paths A and B can be connected to the hard disk for recording. This, in a nutshell, is the EMMA2's ability to record two and watch a third. So, when you are recording two programmes, you can watch a third one (live or playback) using PathC (at least).

The problem with playback is this: copying! In order to copy a recording you have to connect a recording path (A or B) to the playback source, so this would explain why the system does not choose PathC when starting a playback in the absence of recordings. Chase-play will choose PathC for the playback part because the recording is already being made on another path. In fact, whenever a recording is active the system will choose PathC for playback because the system only lets you start a copy when nothing else is recording (what happens when those recordings stop and you're still playing back on PathC would be interesting... I suspect the system will still prevent the copying).

There would appear to be two choices now:
  1. force the system to always use PathC for playback, and give up the ability to copy recordings
  2. find a way to change playback to PathC once a (non-copying) recording has started
View user's profile Send private message Visit poster's website
EMJB
Posted: Tue Dec 11, 2007 9:47 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3645 Location: Maldon Essex
Personally, I would be happy to give up the copy facility in order to get rid of the switching interruptions - I don't think I have ever used it intentionally anyway!

Would it be possible for the fix to allow a TAP to select between the present logic and route C playback? That would be the ideal solution so the user could select the default mode adopted when pressing Play/OK, and the TAP provide some other (presumably less convenient) key for selecting the alternative mode.

EMJB
View user's profile Send private message

Display posts from previous:  

All times are GMT + 1 Hour
Page 4 of 25
Goto page Previous  1, 2, 3, 4, 5 ... 23, 24, 25  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