second timer causes first one to stop recording

[DonLandis]

If this has already been posted as a bug, please point me to it so I can cast my vote.
The 921 is in standby mode when these event failures happen-
I set a timer to record a 90 minute movie. a half hour later, I set a second timer to record a 30 minute program, both are HD sat channels.
After 29 minutes of the first timer movie recorded, the second timer fires and records the pad 1 minute but shuts down the longer movie that was already recording. This has happened consistently for 3 sets of timer events now. I saw somewhere there were reports that lately the 921 fails to do two tuner or dual recordings. If nobody knows of such a bug report I'll post one in the bug - poll forum.

[Allen Noland]

What HD channels were you recording from?

[DonLandis]

Allen- In the first instance, I had started a movie on showtimeHD and the second timer was a 30 minute program from HDNet. But, does this really matter which channels? I had the same problem with other channels, all sat HD, as well.

This all happened last week while I was away so the 921 was in standby all week, except for the recordings.

The only thing I can't answer is what channel I left the 921 tuned to but I know it was a sat channel.

Also, on 4 of the 6 recordings, other bug where the wrong program intended showed up in the list with a sub list of the pad timers as well. In the case of the aborted movie the pad start time and the first half hour was listed but no ending pad because the recording was aborted early.

[Allen Noland]

I'm going to try it tonight and see what happens.

[Jerry G]

I'm going to try it tonight and see what happens.

I'm not sure it matters how your test comes out. What Don described used to happen to me all the time with the prior software. So far it hasn't happened with the current software (but I've only tried it a few times). But there isn't a time when I set two timers that overlap that I don't worry that this problem will happen again. The fact that this has happened to Don on a number of occasions only makes me more apprehensive and demonstrates the bug is still there but with variable occurrence amongst the various 921 boxes.

[DonLandis]

You make an important statement, Jerry.

I have been concerned for quite some time that many of the 921 bugs seem to occur at random. It seems to me that is digital processing is so on-off that if a flaw in the code exists, it should produce consistent results. But to the contrary, many if not all the recent bug reports seem to produce random occurrences. Tonight, I set two long form timers and set some short form timers simultaneously. So far all have fired without flaw.

So, what is it that interferes with the system that causes the system to react to the same software instructions differently at different times? I believe one needs to look at the complex science of chaos to understand what is happening here. Possibly that failure begins to happen when memory is requested for an event and it is not ready due to previous activity occupying the limited system resources. Maybe some operations in the system does not release memory for others and its function begins to break down. Describing what one does leading up to a failure may be overly simplified. In other words, how do you describe the chess moves that led to check mate? Do you describe the moves from the first one of the game or just the previous 4 moves or 6 moves? Does the 921 system begin fresh from a power on state or does it begin fresh from a standby reboot procedure? Is memory breakdown the root cause or is it something else that changes?

[bbomar]

I have been concerned for quite some time that many of the 921 bugs seem to occur at random.

So, what is it that interferes with the system that causes the system to react to the same software instructions differently at different times? I believe one needs to look at the complex science of chaos to understand what is happening here. Possibly that failure begins to happen when memory is requested for an event and it is not ready due to previous activityoccupying the limited system resources. Maybe some operations in the system does not release memory for others and its function begins to break down. Describing what one does leading up to a failure may be overly simplified. In other words, how do you describe the chess moves that led to check mate? Do you describe the moves from the first one of the game or just the previous 4 moves or 6 moves? Does the 921 system begin fresh from a power on state or does it begin fresh from a standby reboot procedure? Is memory breakdown the root cause or is it something else that changes?

The stuck aspect ratio is a good example of the randomness of 921 failures. Sometimes I reboot more than once a day to clear this problem. Other times I can go for a week or more with no problem.

I wonder if this "randomness" is not truely random but, rather, a function of the usage pattern (i.e. the chess game) prior to the failure. Some of the variation in observed failures may due to differences in how the 921 is used by different people.

One cause of random failures can be hardware related, like inadequate timing or noise margins, which can vary with temperature and possibly line voltage. However, such failures usually result in hard lock-ups or illegal instruction errors or the like.

Memory leaks have been mentioned as a possible cause of 921 failures and I think it remains the most likely candidate. What happens is that a process will allocate memory for its purposes and then deallocate that memory when it terminates. However, if the process terminates abnormally it may bypass the deallocation and that memory remains lost to the system. The operating system will return an error code if a memory allocation fails. The question is, what to do if an error code is returned? After all, if an allocation fails it could be due to either memory leaks or to a temporary high load on system resources. If the latter, then we should wait and try again. However, if the former, then what? Reboot? Well, rebooting would take several minutes and so is not a very attractive option, and might not be the right option anyway. So, I suspect the 921 programmers choose to wait and try again. However, this can result in a blocked process that waits forever. Different usage patterns may result in different processes being blocked, like the process that controls the aspect ratio and format buttons. Also, as memory resources become low more waiting takes place and the 921 becomes more and more sluggish and eventually fails in some way. A reboot reinitializes the system and memory resources, thus "fixing" the problem.

If memory leaks are involved, the root cause may be buried deep in the guts of the operating system, well below the level that the 921 programmers are dealing with. In fact, if this were not the case, you would think that a more elegant solution than a nightly reboot would have been implemented.

[SimpleSimon]

If memory leaks are involved, the root cause may be buried deep in the guts of the operating system, well below the level that the 921 programmers are dealing with. In fact, if this were not the case, you would think that a more elegant solution than a nightly reboot would have been implemented.I must disagree. Memory leaks are generally from applications (not the operating system) allocating and not relasing global storage. Local storage would normally be cleaned out when a task ends - of course, if the task is sucking RAM and not terminating, as I'm sure exists in the 921, then that's a problem, too. The auto-reboot clears both.

The first multi-task, global-storage type systems had this problem all the time - 30 years ago. Nothing changes - bad design is bad design, period.

As an aside, I might try to stuff some more RAM in my 921 and see what happens. Of course, I've said that before, and haven't tried it yet.

[DonLandis]

Simple Simon- Not my field so excuse me if I sound obtuse-

I thought that memory leaks and such are "system resource" consumption. In a windows machine, if you have a problem with using up and not releasing "system resources" adding additional ram does not seem to help, only fixing the application that creates this hog will.

Second, do you know if the 921 system is a collection of applications or actually a single app with subroutines? I don't see how adding more ram would help if it is a single app that's all loaded at boot time anyway.

[KKlare]

You can have memory leaks from applications or the OS, usually associated with unanticipated events like button presses or timers when working on something not expecting them. This can mess up the return stack so that prior screens/apps/handlers do not get unloaded. The real problem comes when there is no more memory to leak into and it overwrites the system or a still working app.... So adding memory might postpone the problem but eventually **it happens. Maybe you could get 2 whole days or even a week.
-Ken

[Ron Barry]

Simple Simon- Not my field so excuse me if I sound obtuse-

I thought that memory leaks and such are "system resource" consumption. In a windows machine, if you have a problem with using up and not releasing "system resources" adding additional ram does not seem to help, only fixing the application that creates this hog will.

Second, do you know if the 921 system is a collection of applications or actually a single app with subroutines? I don't see how adding more ram would help if it is a single app that's all loaded at boot time anyway.

Are you asking if the 921 is single threaded? I can assure you the 921 has sub-routines even it if to single threaded even though it is not. The 921 is most likely multi-threaded. Well since it sit on top of an OS by definition is it not a single application. Is it a single application on top of the OS, not sure. My guess would be it is not, but I have seen it done both ways.

As to Memory leaks, adding more memory may or may not help. Depending on the OS implemenation, one could run out of file memory handles before actually exhausting all the memory so adding memory may not help. A lot of this depends on how memory is carved up and a number of other factors. However, adding memory might help but by help I mean just make it longer before you run out of memory. You are prolonging the issue.

Simon is correct that it usually is the processes running ontop of the OS that results in a memory leak, however, the OS can also contain a memory leak since it is a application too but in most cases it is the running process that causes the memory leak.

If it is a single App... Adding more memory may take the 921 longer to get into resource contention. Hard to say, but would be an interesting experiment. Being a single app or multiple apps in most cases have nothing to do with exhausting memory. If a process allocates a chunk of memory and does not free it that chunk of memory is not available for itself or another process. Now, if you have a virtual memory model that piece of memory can get swapped out but eventually you will run out of memory or file descriptors(memory handles).

There are a lot of other factors that could come into play, Here is one to consider. Two processes with a queue between them, When the queue fills up and as a result the sending process drops the request on the floor because of poor error handeling, this may result in a number of usually behaviors and may even look like a memory leak. This example, could be a possible explaination why some people are seeing issues that others arn't. Their particular use case results in a queue overflow. Ofcourse.. this paragraph is purely speculation with no evidence to support it. ;)

[Ron Barry]

The stuck aspect ratio is a good example of the randomness of 921 failures. Sometimes I reboot more than once a day to clear this problem. Other times I can go for a week or more with no problem.

I wonder if this "randomness" is not truely random but, rather, a function of the usage pattern (i.e. the chess game) prior to the failure. Some of the variation in observed failures may due to differences in how the 921 is used by different people.

One cause of random failures can be hardware related, like inadequate timing or noise margins, which can vary with temperature and possibly line voltage. However, such failures usually result in hard lock-ups or illegal instruction errors or the like.

Memory leaks have been mentioned as a possible cause of 921 failures and I think it remains the most likely candidate. What happens is that a process will allocate memory for its purposes and then deallocate that memory when it terminates. However, if the process terminates abnormally it may bypass the deallocation and that memory remains lost to the system. The operating system will return an error code if a memory allocation fails. The question is, what to do if an error code is returned? After all, if an allocation fails it could be due to either memory leaks or to a temporary high load on system resources. If the latter, then we should wait and try again. However, if the former, then what? Reboot? Well, rebooting would take several minutes and so is not a very attractive option, and might not be the right option anyway. So, I suspect the 921 programmers choose to wait and try again. However, this can result in a blocked process that waits forever. Different usage patterns may result in different processes being blocked, like the process that controls the aspect ratio and format buttons. Also, as memory resources become low more waiting takes place and the 921 becomes more and more sluggish and eventually fails in some way. A reboot reinitializes the system and memory resources, thus "fixing" the problem.

If memory leaks are involved, the root cause may be buried deep in the guts of the operating system, well below the level that the 921 programmers are dealing with. In fact, if this were not the case, you would think that a more elegant solution than a nightly reboot would have been implemented.

Couple points here.

1) My experience has been that if a process terminates, the memory associated with that process is returned back to the memory pool. In some cases there are APIs were this the memory would not be freed, but in general my experience is that memory is freed. The cases where id does not get freed is usually APIs involing intra-process communicaiton.

2) Most applications allocated and free memory as part of the life cycle of the process. Ofcourse there are exceptions, I am currently working on a system that does not do any malloc or frees. It is all statically allocated. But in mose cases memory is not allocated at start and freed at termination.

3) Most likely the 921 process or processes are started upon start up and do not terminate until the box is shutdown via a safe reboot. (Pushing the finger for 10 seconds). Ofcourse I am assuming this initiates a safe shutdown.

4) I agree that a the randomness could be contributed to different use cases. I also would through in variations in external influences.

5) I believe the nightly reboot workaround was mainly added because memory leaks can be very hard to track down. I believe the main reason for the reboot is memory leak related. Memory corruption issues could also be on the list of possible reasons for the issues we are seeing.

6) I believe the reason that the reboot was added was not because the memory leaks are in the OS, but because they needed a workaround until the memory leaks could be squashed. When NT was released, IT departments were rebooting the NT servers nightly for the exact same reason.

[SimpleSimon]

Ron's right on the money with his speculations.

I have NO doubt it least some of them are correct, especially the ones about additional RAM possibly delaying the inevitable - but it's 99% sure that it will NOT prevent them - although I did run into a strange case once where adding just a little RAM actually DID totally fix the symptoms - root cause was that normal operation needed just a little more than was available.

There's other possible improvements with additional RAM - like maybe it will be used for more buffer space and might help with the recorded dropouts we sometimes see. Just dreaming.

As for multi-task vs. single-thread, and tasks being started and terminated during a single boot. I believe that the 921 IS a multi-tasking system. I base this mainly on how search seems to operate - and sometimes not terminate correctly, or belatedly.

[Ron Barry]

Multi-tasking.. hmmm threaded or process based. ;) I am sure it is.. THere is no way the 921 would be single threaded. Well could be multiple singled threaded processes but I doubt it since it is on top of Linux.

As to your thought Simon, Yeap... there are cases where adding memory could help if you are in a memory starved system and it is swaping. Or like you said, the application needs a bit more than what is in the box. However, I would lend more towards a slow memory leak since it does have the autoboot feature.

And if more memory results in reduced swapping to the disk that most definitely could help things like dropouts. Not sure if the 921 swaps or not. I would almost expect that it would not, but could be worong.

Like I said.. would be a very interesting experiment. You might even find that the 921 will not run if memory was bumped up. They might actually check for it. ;)