T4 possible software problem?

ccspack · Post by **ccspack** » Wed Jul 01, 2015 22:37

It seams that ever since I start recording with the T4 random timers started recording nothing in them, 0mb files. Or so I thought, I've noticed it seams to be when more then one timer starts at the same time, then on that turner adjoining shows are doing the same thing. It's not signal. As if I stop the recording then start it again the recording starts properly. I noticed it tonight as it was happening so I went to live TV and found all channels on that frequency black. So the turner didn't start correctly? If I start 4 recordings on four different frequencies manually it records fine. I have been able to replicate the fault several times by setting 2 recordings to start at the same time. Flick to live TV & it's blank on the frequency that has the 0mb file size. Not sure how to fix it.

ccspack · Post by **ccspack** » Sat Jul 04, 2015 20:59

Am I the only one with this problem? So I have to find a solution. I have change the preferred record tuner to C, so now I'm right unless 3 tuners start to record at one, witch is better but it still create problems a couple times a week.

ccspack · Post by **ccspack** » Tue Jul 07, 2015 13:26

After spending way to much time trying to sort out this problem, I am convinced I have a fault in my unit. I have used the USB that cam with the unit, left the default setting in place & still get the problem, I then installed the latest Beta firmware, via USB, from the web site, still with default settings. It still creates a empty recording when starting 2 or more times (on different frequencies) at the same time. This is when the unit is OFF when they start or if the unit is just in the menu (ie no TV running in back ground) or when watching a recording (ie no tuner in use). So if I am watching a different channel (frequency) when the times start, they all start fine (tuner A is skipped as I am using it).

So I have deduced that if more then one timer (on different frequencies) starts together with tuner A involved, then all of the recordings on one frequency will be empty until the tuner has changed frequencies again (ie all shows on that frequency that overlap).

Hope this all makes sense to someone, but like I said I think my unit is just faulty.

MrQuade · Post by **MrQuade** » Tue Jul 07, 2015 13:48

Actually, this did get mentioned yesterday as well.
viewtopic.php?f=55&t=9250&p=123384#p123384

Are you using IceTV for your timers too?

prl · Post by **prl** » Tue Jul 07, 2015 14:01

MrQuade wrote:Actually, this did get mentioned yesterday as well.
viewtopic.php?f=55&t=9250&p=123384#p123384

Are you using IceTV for your timers too?

This doesn't sound very like the problem talked about there.

I do sometimes get recordings that I wanted to record showing 0 btyes and 0:00 duration, but I don't think it's related to the problem in that topic.

I'm not sure that my zero-length recording problem is the same as ccspack's, because I really can't work out from his post what the circumstances are that cause the problem.

ccspack · Post by **ccspack** » Tue Jul 07, 2015 14:03

Yes, but I only have a t4

MrQuade · Post by **MrQuade** » Tue Jul 07, 2015 14:10

The problem in this thread is that when two recordings fire at the same time, one of them will be 0MB.

In Fester's last post he mentioned this:

Fester1952 wrote: So I have set four timers on four separate networks though IceTV and one will always record with a zero MB file.

It sounds as if they could be related, but describing different manifestations of the same issue?

MrQuade · Post by **MrQuade** » Tue Jul 07, 2015 14:12

ccspack wrote:Yes, but I only have a t4

The T3 is not related to the issue in the other thread. it is just there to demonstrate that the problem is ONLY happening on the T4.

prl · Post by **prl** » Tue Jul 07, 2015 14:16

MrQuade wrote:The problem in this thread is that when two recordings fire at the same time, one of them will be 0MB.

In Fester's last post he mentioned this:

Fester1952 wrote: So I have set four timers on four separate networks though IceTV and one will always record with a zero MB file.
It sounds as if they could be related, but describing different manifestations of the same issue?

I missed that bit

Looks like I need to start trying to break things, then

ccspack · Post by **ccspack** » Tue Jul 07, 2015 14:38

After reading the recent post I got a little excited & disabled IceTV, but unfortunately the problem isn't fixed. However much more unlikely to happen as the normal EPG is a lot more precise with the start times (less likely to start all at once).

I think the reason that not many people are finding this issue is because, if you leave your unit on live TV, Tuner A is in use & that the problem only seams to happen when tuner A is firing up with another turner. I however nearly always leave the T4 in the Media player (with the black screen after stopping a show [makes it quieter]), therefore tuner A is the first to be used by the timer.

Fester1952 · Post by **Fester1952** » Tue Jul 07, 2015 16:31

I have just been messing with the tuner configuration and tried Tuner "A" as preferred and Tuner "D" as preferred tuner for recordings and the 0MB file didn't happen with two timers initiated from IceTV.
I tried four IceTV timers initiated at exactly the same time earlier on with the default tuner config and one file was 0MB.

I have Masterchef and The Voice set for tonight, but not from IceTV. I am just messing with anything to see what replicates the issue.
Are all your four tuners showing good signal strength, checked mine and all are good so that rules out a crook tuner.

prl · Post by **prl** » Wed Jul 08, 2015 17:31

I've been able to reproduce this problem by simply setting up four 5-minute timers with exactly the same start time on services from four different broadcasters (e.g. on ABC, Seven, Nine and Ten) while watching live TV on a fifth broadcaster, in that case, SBS.

I can't force the same issue on a T3 with three simultaneous recordings, but I suspect that it would also be the same on a T3 with a USB tuner and four recordings starting simultaneously.

I doubt that the problem is directly caused by IceTV, but there is a possible association (which I think I saw someone post, but I can't find it now). Timers set by IceTV are based on a program start time that IceTV rounds to the nearest 5 minutes. The broadcast EPG is given to more precision (though not necessarily more accuracy), so four programs that share the same scheduling slot are more likely to share the same EPG start time in IceTV than in the broadcast EPG, especially if the timer set in the broadcast EPG is set for the current evening, but after the broadcasters send out the evening's "actual" start times.

I've been able to reproduce the problem with the default tuner setup (preferred tuner Tuner A), with the timers set and left to run while watching live TV using Tuner A. It only seems to happen reliably if I have live TV set to a fifth broadcaster when the four timers start.

I'll try to capture some debug logging to see if it gives a hint as to what's going on.

prl · Post by **prl** » Wed Jul 08, 2015 18:40

Hmmm... I may have to revise my recipe slightly.

Four timers starting simultaneously on four different broadcasters, and live TV set to a fifth broadcaster when the timers start.

prl · Post by **prl** » Wed Jul 08, 2015 18:44

I now have a debug log showing an error when the fourth recording starts up

ccspack · Post by **ccspack** » Wed Jul 08, 2015 18:53

Big question is, is it easily fixable?

prl · Post by **prl** » Wed Jul 08, 2015 18:59

ccspack wrote:Big question is, is it easily fixable?

Absolutely no idea. It's almost certainly in code that I've never looked at before.

I'm going to do some more testing tomorrow and I hope I can post some details from the logging on the beta forum.

prl · Post by **prl** » Thu Jul 09, 2015 16:52

I've amended some of the information in my earlier post about reproducing this problem.

prl · Post by **prl** » Thu Jul 09, 2015 16:54

While it seems that the four simultaneous timers on four different broadcasters and live TV on a fifth broadcaster seems to trigger this problem reliably, it's not necessary to have that many simultaneous recordings starting to trigger the problem.

Last night, on our "in-use" T4, I had these recordings scheduled:

Code: Select all

7TWO     16:25-17:55
SBS TWO  18:25-19:55
7TWO     18:25-19:55 ***
Prime 7  19:25-20:30 ***
Prime 7  20:00-21:00 ***
ABC      20:25-21:25
SBS ONE  20:25-21:55
SC10     21:40-23:10
7TWO     22:25-23:55

The ones marked *** had zero length recordings, but it all started when only two simultaneous recordings on different broadcasters started.

Also the tuner (non-)allocation carried forward into the two subsequent overlapping recordings from PRIME. It appears that once they finished the tuner (non-)allocation to PRIME allowed recordings of PRIME to record correctly (e.g. at 22:25).

While the recordings on PRIME were running between 18:25 and 21:00, I could watch live TV from any broadcaster except PRIME. When I tried to view PRIME services, I got a black screen and no audio.

Fester1952 · Post by **Fester1952** » Thu Jul 09, 2015 17:15

Exactly what I am getting, I'm glad you have picked it up as well, it was driving me nuts trying different combinations of tuner and IceTV and auto timers.

ccspack · Post by **ccspack** » Thu Jul 09, 2015 17:39

Having first posted about this over a week ago and getting not response for a week. Subsequently thinking I was all alone to try and sort out or get my unit replaced. I'm glad it's easy to replicate and have faith that a software fix will be found.

prl · Post by **prl** » Thu Jul 09, 2015 18:54

The people you've been interacting with on the forum about this problem are simply other Beyonwiz users. I work on Beyonwiz firmware in my spare time. I've been busy with other issues recently, but I posted about the zero length recording problem in the beta forum in late May (well before your post), and discussion about the technical details is going on there in parallel with posts here.

I didn't have any useful insights until I saw hints from you and Fester1952 about how I might be able to reproduce the problem.

I've started looking at the code that is involved with selecting a tuner to use for a recording, but so far I've made little headway.

The only Beyonwiz employee who posts on the forum is Wiz HQ (and he's the boss).

ccspack · Post by **ccspack** » Thu Jul 09, 2015 22:24

I am happy to help if I can, as I have done a lot of testing with this. I also appreciate the help you offer to fix the problem, hopefully it's not too complicated to fix.

ccspack · Post by **ccspack** » Fri Jul 10, 2015 19:16

I can find where this being discussed in the beta section, are you able link us to it?

prl · Post by **prl** » Fri Jul 10, 2015 19:20

ccspack wrote:I can find where this being discussed in the beta section, are you able link us to it?

That doesn't make sense, unless you meant "can't".

Anyway, the beta forums are closed to people other than the beta testers. In fact, the T4 beta forum is somehow some kind of sanctum sanctorum only open to a few beta testers. I could post a link, but only people who can get into the T4 beta forum would be able to follow it.

MrQuade · Post by **MrQuade** » Fri Jul 10, 2015 19:23

Essentially the issue is that if tuners A and B are simultaneously called into service for a recording, then the recording on Tuner A will be blank.

This means that you could, for example, set two simultaneous recordings on separate channels, and be in standby (so no tuners are active when the timers fire).
Or, you need to be live viewing Tuner C or D with tuners A and B not in service, then have two recordings fire simultaneously, again on separate channels.

There are some other more complicated triggers, but those are the simple cases.

I'll not go into any more detail at this stage though.

Now it is just a case of finding and fixing the right bit of code

prl · Post by **prl** » Fri Jul 10, 2015 19:24

Thanks to some dogged detective work done by MrQuade, another trigger for this problem has been found.

If live TV is being taken from any tuner apart from Tuner A, and two (or more) simultaneous recordings are started on different broadcasters from the one being viewed live, Tuner A won't get properly allocated to the recording, and yu'll end up with an empty recording. You also won't be able to view any of that broadcaster's channels in live TV.

(snap!)

ccspack · Post by **ccspack** » Fri Jul 10, 2015 20:41

prl wrote:
ccspack wrote:I can find where this being discussed in the beta section, are you able link us to it?
That doesn't make sense, unless you meant "can't".

Anyway, the beta forums are closed to people other than the beta testers. In fact, the T4 beta forum is somehow some kind of sanctum sanctorum only open to a few beta testers. I could post a link, but only people who can get into the T4 beta forum would be able to follow it.

Ok fair enough.

ccspack · Post by **ccspack** » Fri Jul 10, 2015 20:49

prl wrote:Thanks to some dogged detective work dome by MrQuade, another trigger for this problem has been found.

If live TV is being taken from any tuner apart from Tuner A, and two (or more) simultaneous recordings are started on different broadcasters from the one being viewed live, Tuner A won't get properly allocated to the recording, and yu'll end up with an empty recording. You also won't be able to view any of that broadcaster's channels in live TV.

(snap!)

It happens to me a lot, as at the time most shows start, I am watching a recording or T4 is sitting within a menu (I prefer no TV to display after stopping a show). Hope we can find the fix for this easily.

mister_bimbo · Post by **mister_bimbo** » Mon Jul 13, 2015 16:13

Hi Peter,

prl wrote: If live TV is being taken from any tuner apart from Tuner A, and two (or more) simultaneous recordings are started on different broadcasters from the one being viewed live, Tuner A won't get properly allocated to the recording, and yu'll end up with an empty recording. You also won't be able to view any of that broadcaster's channels in live TV.

(snap!)

I may have found a further permutation of this: I've had some recordings fail last Friday night with the 0MB file size error. The first recording that this failed on was ABC - it seemed that the timer was set to start at the same time as another timer on 7TWO ... the 7TWO timer recorded correctly. There was only these two timers set to record at this time.

What was interesting is that the immediately next timer set to record on the same tuner (ABC) that had generated the 0MB file, also produced a 0MB file size. I noticed that the first invalid recording was scheduled for 20:25 - 21:45, while the next timer scheduled to start recording at 21:25 (recording was for 21:25 - 22:45): both timers were active at the same time ... my interpretation is it seems that if the timer for the first invalid (0MB size) recording is still active when the next one kicks off on the same tuner ... the second (and perhaps subsequent) timers will also fail with the 0MB file size recording.

That said, I thought that I'd go through my recordings and adjust the timers (via the web interface) so that no 2 recordings start at the same time. Unfortunately, IceTV overwrites the changes I make and reinstates them as per the IceTV schedule. Is the only way to delete these IceTV recordings and then manually schedule them (say using a combination of the EPG & edit)..?

Cheers,
David

prl · Post by **prl** » Mon Jul 13, 2015 16:55

mister_bimbo wrote:... What was interesting is that the immediately next timer set to record on the same tuner (ABC) that had generated the 0MB file, also produced a 0MB file size. ...

Yes, I've had an instance of that where the original problem happened on 7TWO, but the overlapping sequence of recordings initially on 7TWO and then on Prime 7 and again on Prime 7 all had zero length. A later recording that didn't overlap with the earlier ones recorded just fine.

It seems that the normal mechanism that re-uses tuners for concurrent recordings from the same broadcaster (the concurrency is often because of padding) ensures that the incorrectly configured tuner gets reused in that state until it is no longer being "used". Once it's been released, it's OK to use again (but still subject to this bug biting).

MrQuade · Post by **MrQuade** » Mon Jul 13, 2015 17:31

Yep. the first recording buggers Tuner A, and it stays buggered until you stop using Tuner A, or force it to a new broadcaster (change channels)

MoDementia · Post by **MoDementia** » Tue Jul 21, 2015 11:02

Any fix available yet, I have also experienced the zero byte recordings

prl · Post by **prl** » Tue Jul 21, 2015 11:22

No, I'm still looking at it.

scotty · Post by **scotty** » Tue Jul 21, 2015 20:22

I seem to have had this issue a few times recently, however with slightly different symptoms.

My preferred tuner for recordings was set to auto.

Two recordings start at the same time from two different networks.

Look in Media and the files say 0MB, but if you move the selection off the file then back it then displays the correct file size.

Instead of empty recordings I've had one show record fine and the same show record again in the other file with the name and info of the recording it should have been.

While the recordings were happening, for example on 7 and 10, you could view channel 10 by going to 7.

Anticipating the same problem tonight I changed my preferred tuner for recordings to D and was viewing another network not due to record using tuner A. The recordings started fine and are recording the correct channels. The only strange thing is neither used tuner D. They're using tuners B and C.

Not sure if any of this helps or hinders tracking down the issue!

Scotty

prl · Post by **prl** » Tue Jul 21, 2015 23:06

Thanks for the info.

The "zero length but non-zero duration" bug is an annoying but superficial problem that affects only the display of the file size. I've tired to nail it down, but so far with no success.

The actual "zero length recording" bug where both the recording size and duration is shown as zero for typical recordings is more serious.

In that case, the recording files aren't actually of zero length, through they don't include any useful information.

The problem appears to be that when the two recordings start simultaneously, the output of the demux for the "good" recording is also used for the failed recording. However its stream ids don't match with what is expected by the filter that selects what parts of the total broadcast stream, and only the control stream with fixed stream id '0' is recorded.

This problem occurs early (within the first seconds of the recording starting).

However, it's not impossible that under some circumstances, this bug might cause the same problem that you described, of a recording getting duplicated.

I'm still trying to find where it is that the output of the wrong demux is being picked up. I thought I'd found it yesterday afternoon, but I've been unable to reproduce the debug output I saw then, even though I still generate the same recording result.

Anyway, if/when I find the cause of the "zero length" recording problem, I'll also try to see if it could cause other misdirection of where the data streams go.

Fester1952 · Post by **Fester1952** » Wed Jul 22, 2015 07:46

prl wrote: However, it's not impossible that under some circumstances, this bug might cause the same problem that you described, of a recording getting duplicated.

I reported that earlier in the IceTV thread and I am getting the same as Scotty, maybe I didn't explain it as well as he has.
viewtopic.php?f=55&t=9250

prl · Post by **prl** » Tue Jul 28, 2015 17:05

[Lack of] progress report: the bug appears to be in the kernel drivers at the point where the UI code connects a frontend (tuner) to a demultiplexer. The two demultiplexers appear to be receiving the same data from two setups that should use different frontends, even though the two frontends appear to have been tuned to the correct (different) broadcast channels.

prl · Post by **prl** » Sun Aug 02, 2015 13:08

There's now a (major) bug entry in the issue tracker: Bug #408: On T4, when recordings start simultaneously, one may be empty.

There is now some useful progress, too.

The problem appears to be with the fact that when multiple recordings from different broadcasters are started simultaneously, setting up each tuners for its broadcast channel is a multi-step process. When more than one recording is started simultaneously on different broadcasters, the tuners are set up concurrently, with accesses to different tuners interleaved. This is clearly intentional and works properly on the T2 and T3.

Strangely, on the first simultaneous recording of this type after a reboot of a T4, the tuning is sequential, and the problem can't be replicated (e.g. with the two-recording recipe that MrWade discovered). Subsequent repeats of the same recording scenario without a reboot do result in a failed recording.

No wonder this has been a bit hard to nail down!

Anyway, from the observation that the recordings all get made if the tuners are set up sequentially rather than concurrently, I tried forcing sequential tuner access in the tuner setup code. This seems to have worked around the problem. It does slow down the recording startup, from less than a second for the concurrent code to between 2-3 sec in the sequential code.

I'm still doing some testing, but I'll make the workaround available to the source repository in the next couple of days. What happens next with it will be up to peteru and Beyonwiz.

The underlying problem has not been found, unfortunately, but appears to be due to a hardware or driver difference on the T4. Because the ultimate cause hasn't been found, I can't be completely sure that the workaround will always prevent the problem. It's also still unclear whether the incorrectly duplicated recordings that a couple of users have reported are due to the same underlying prblem. It's possible that they are, but without a way to replicate that problem, it's hard to know.

prl · Post by **prl** » Sun Aug 02, 2015 14:06

I have submitted the workaround to the software repository.

peterdeg · Post by **peterdeg** » Wed Aug 12, 2015 09:31

Watching with interest. Will be buying a new PVR in the next month or so. I want the T4 but this would be a killer (I'd never hear the end of it if the boss' recordings failed.)

prl · Post by **prl** » Wed Aug 12, 2015 10:04

peteru is still investigating the kernel and drivers to try to find a definitive solution.

Ukind · Post by **Ukind** » Wed Aug 12, 2015 11:35

I had an issue last night. I tried to delete a location and the box displayed an error message and restarted. Not sure if it is a bug or if it was user error. Can someone please explain how to do this just in case I did something wrong

prl · Post by **prl** » Wed Aug 12, 2015 12:09

Ukind wrote:I had an issue last night. I tried to delete a location and the box displayed an error message and restarted. Not sure if it is a bug or if it was user error. Can someone please explain how to do this just in case I did something wrong

Please start a new topic for a new problem (and give it a meaningful title).

If you get a GUI restart with a black screen full of white text, there should be an error log generated.

You can use FTP to connect to the T4 and download the log to your computer using an FTP client from /home/root/logs on the T4 (or T anything).

The logs have names like "enigma2_crash_1438410792.log". the long number is the Unix timestamp. The most recent one will have the largest number, if the FTP client doesn't show a creation time.

A convenient FTP client is often your browser. Send it off to ftp://root:none@beyonwizt4/home/root/logs/ (if that doesn't work, use the IP address of yout T4 in place of "beyonwizt4"). If it asks for a username, use "root". If it asks for a password, any non-blank string will do (that's the "none" in the URL). Click on the name of the log you want to download, then use File>Save page as... to save the page to your computer.

Then post the log as an attachment to your post about the problem.

When you re-post please describe exactly what you did when you "tried to delete a location". It may be helpful to first read How to create good bug reports in Bug Reporting and Feature Requests.

prl · Post by **prl** » Fri Aug 14, 2015 16:42

My workaround for the "zero length recordings" bug is in a current beta-tester's beta release. Some (so far minor and unrelated) fixes will need to be made before the fix appears in a public beta.

sddawson · Post by **sddawson** » Sun Aug 23, 2015 12:19

Appreciate the efforts to get this bug fixed. Is there a way around it until a fix/bypass is released? For example, if you always leave the unit powered on and watching live TV, does this mean tuner 1 is in use and therefore will minimise the problem?

MrQuade · Post by **MrQuade** » Sun Aug 23, 2015 12:29

sddawson wrote:Appreciate the efforts to get this bug fixed. Is there a way around it until a fix/bypass is released? For example, if you always leave the unit powered on and watching live TV, does this mean tuner 1 is in use and therefore will minimise the problem?

The latest public beta does fix this bug now:
viewtopic.php?f=56&t=9386

It looks pretty stable so far, though some people are reporting some issues with scanning for channels (misses some channels). I haven't seen that issue myself.

In the meantime, yes, as long as both Tuner A and Tuner B are not called simultaneously, then you won't see the problem. However, your suggestion would not always work, though it would greatly minimise the occurence.

Say if you left Tuner A on ABC, then four timers fired for 7, 9, 10, and SBS, Tuner A would then be called into service at the same time as Tuner B, and trigger the bug.

So as long as you aren't in the habit of calling timers for all four tuners at once, then leaving Tuner A tuned to a channel should be a semi-workaround.

prl · Post by **prl** » Sun Aug 23, 2015 12:40

sddawson wrote:... For example, if you always leave the unit powered on and watching live TV, does this mean tuner 1 is in use and therefore will minimise the problem?

As long as you never go into standby or have timers start while you're watching a recording

Standby is pretty much fully powered up, so I'm not sure whether you included that in "powered up".

prl · Post by **prl** » Sun Aug 23, 2015 12:46

MrQuade wrote:...
The latest public beta does fix this bug now:
viewtopic.php?f=56&t=9386

It looks pretty stable so far, though some people are reporting some issues with scanning for channels (misses some channels). I haven't seen that issue myself.
...

I have

If your scan fails to find all channels, it means you can't have all your broadcast channels and get the HDMI IN service into your channel list on a T4 except by hacking.

If the scan doesn't work, you can cancel out of it with RED Cancel and keep your old channel list.

Save your settings before installing the beta from USB so that you can keep your old channel list, in case the scan doesn't find everything.

peteru · Post by **peteru** » Sun Aug 23, 2015 20:58

prl wrote:If your scan fails to find all channels, it means you can't have all your broadcast channels and get the HDMI IN service into your channel list on a T4 except by hacking.

I'm not sure I follow. If you do a scan and it finds some, but not all, services, the scan will still complete and at the end of the LCN assignment HDMI input will be appended to the LCN list. An incomplete scan should not prevent HDMI IN from being present. Are you seeing something different? If so, can you please elaborate?

About the Forum

Join us