|
||||||||
Foxsat-HDR Issues |
![]() |
|
|
Thread Tools | Search this Thread |
|
|
#26 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
Re recovery after mains interuption
I will test this again tomorrow in case I've got it wrong. It may be relevant that, (as I said), you get different results if you turn it off by the power switch on the back or by the wall socket. The switch on the back may not be a total power on/off switch, i.e. there may still some live circuits when it is off. In view of this,turning off at the wall socket is the only way to truly simulate a mains failure Quote:
Re pause live tv
Page 65 section, 12 says "the product buffers the channel you are watching to the hard drive (2 hour period), this enables you to pause live tv, rewind to the point you changed to the channel and fast forward". From this, I assume you should be able to watch up to 2 hours in 'time slip', when you press play, after pausing live tv In practice, I find that if you pause live tv and start watching again, the program stopped recording at that program's actual end time Geof The pause is mentioned and then as a sub-paragraph "Note: Pressing Pause while watching live TV will increase the delay from the point you have paused to the live broadcast. You will be able to use fast forward or skip-forward functions during this time. To go directly to the live broadcast press the stop button." If they have modified the manual it's an indication that we are not going to get it fixed
|
|
|
|
|
Please sign in or register to remove this advertisement.
|
|
|
#27 |
|
Inactive Member
Join Date: Oct 2009
Posts: 3,089
|
^^^ There's another little bug in this function. If you pause for a short time (i.e. a few seconds) then when you press play it plays a second of so of the buffer and then lurches into live play. Not something that's ever likely to cause any real problem but it demonstrates just how lax their testing of this feature was.
|
|
|
|
|
|
#28 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
|
|
|
|
|
|
#29 |
|
Forum Member
Join Date: Feb 2004
Location: Sunny France (sometimes)
Posts: 1,019
|
We had a thunderstorm here this afternoon and as it happens there were two brief power interruptions (maybe a minute or so) while I was watching the athletics. Both times the HDR rebooted into full power-on state.
|
|
|
|
|
|
#30 |
|
Forum Member
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
|
Quote:
^^^ There's another little bug in this function. If you pause for a short time (i.e. a few seconds) then when you press play it plays a second of so of the buffer and then lurches into live play. Not something that's ever likely to cause any real problem but it demonstrates just how lax their testing of this feature was.
|
|
|
|
|
|
#31 |
|
Inactive Member
Join Date: Oct 2009
Posts: 3,089
|
Quote:
I have had the same thing happen on Sky+, Sky HD, Freeview PVRs and a generic FTA PVR and I would suspect it is not so much a software problem but a hardware one caused by the buffer the HDD itself uses and the missing few seconds are not actually on the hard disk but still in the buffer and due to this the receiver thinks it has come to the end of the recording and returns to live play. 8Mb buffer would hold roughly 14 seconds of SD and 3.5 seconds of HD recording.
It's something they could easily sort out but so unlikely to really bother anyone that it's probably not on the radar. |
|
|
|
|
|
#32 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Very interesting - I tried pause a few times - I thought for about 1 min - but I guess I might not have left it for sufficient time (I have a replaced the disk with a 1TB WD10EADS with a 32MB buffer). 14 secs * 4 = 58 secs Will try again.
Test Result: Yes waited 2 mins this time and it buffers fine. So if Humax go it for larger disks in this or future models the importantance of this could increase. Last edited by REPASSAC : 02-08-2010 at 10:26. Reason: Added testing results. |
|
|
|
|
|
#33 |
|
Guest
Join Date: Apr 2004
Posts: 957
|
Quote:
4. Lip sync issues after skipping around in a recording, either by entering time or using the skip fwd/back. Not an easily reproducible problem and as such I can understand it is difficult to fix but it is very annoying just the same.
![]() Therefore I record it (the whole prog) and when I get back I play it and skip directly to Q3 by entering the time and pressing OK. Lips were well and truly un-synched! |
|
|
|
|
|
#34 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
We had a thunderstorm here this afternoon and as it happens there were two brief power interruptions (maybe a minute or so) while I was watching the athletics. Both times the HDR rebooted into full power-on state.
This is much as Bob-Cat had hinted at - something would need modication in the pre-boot process. But I would think that something must be saving the previous power state - for this to be different depening on the previous state. If this were changed to always save the state as On then would this solve the problem? (as this must be done by the main piece of firmware) No one would mind that after a power cut their box came on until the auto power saving kicked in. |
|
|
|
|
|
#35 |
|
Forum Member
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
|
Quote:
That's interesting.
It's something they could easily sort out but so unlikely to really bother anyone that it's probably not on the radar. |
|
|
|
|
|
#36 |
|
Inactive Member
Join Date: Oct 2009
Posts: 3,089
|
Quote:
I doubt it as you would have to wait for the buffer to flush to hard disk and that would cause a pause in playback as there is no data to process in the meantime. Also if another recording is taking place at the time this could cause glitches in that recording by forcing smaller than normal chunks from the buffer.
The standard and correct technique to use for this sort of buffering is to use the RAM as a circular buffer and move chunks off to the hard drive as necessary. In this instance you should continue to do exactly that. What's more likely is that they simply didn't bother to write a routine to playback from the RAM buffer - an action that would only be necessary if you paused a live programme for a length of time smaller than that held by the buffer. We can verify that by checking to see if an HD programme will correctly handle a smaller pause than an SD one. |
|
|
|
|
|
#37 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
I don't see that.
The standard and correct technique to use for this sort of buffering is to use the RAM as a circular buffer and move chunks off to the hard drive as necessary. In this instance you should continue to do exactly that. What's more likely is that they simply didn't bother to write a routine to playback from the RAM buffer - an action that would only be necessary if you paused a live programme for a length of time smaller than that held by the buffer. I don't share davemurgatroyd's fear that this would be noticable - Normally the return from these calls is very quick as the actual processing is done by another process using non maskable interupts for the minimun time necessary and most of the work is done by hardware. |
|
|
|
|
|
#38 |
|
Guest
Join Date: Apr 2004
Posts: 957
|
Quote:
But in thus the case the RAM is on the hard disk -
I do find it amazing how bad the performance of this box is with respect to how it handles recordings, live-pause, guide, and iPlayer when it is using a processor 100s of times more powerful than the original IBM PC. |
|
|
|
|
|
#39 |
|
Forum Member
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
|
Quote:
But in thus the case the RAM is on the hard disk - I am not sure this is addressable by the box - It's years since I wrote interupt service routines - but I seem to remember that (on a PC) you had to use a call to write to commit the cache to disk.
I don't share davemurgatroyd's fear that this would be noticable - Normally the return from these calls is very quick as the actual processing is done by another process using non maskable interupts for the minimun time necessary and most of the work is done by hardware. |
|
|
|
|
|
#40 |
|
Forum Member
Join Date: May 2005
Location: Redditch Worcs
Posts: 17,289
|
Quote:
That is OK if you are only pausing one programme but what effect would flushing the cache have on another recording on a different channel at the same time remember you may have data from two recordings in the buffer - suddenly a different sized block of data in the middle of a recording - is that allowed for in the playback spec
|
|
|
|
|
|
#41 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
That is OK if you are only pausing one programme but what effect would flushing the cache have on another recording on a different channel at the same time remember you may have data from two recordings in the buffer - suddenly a different sized block of data in the middle of a recording - is that allowed for in the playback spec
Quote:
Make that up to 3, if the recordings are from the same transponder the hdr is recording two channels and also recording a 3rd viewed channel to the time shift buffer.
Think of HDR as a PC - It's basically running a flavour of Unix (linux) - see manual section 14 "Open Source Software Notice". Like a PC you can run multiple processes - each knows nothing of what the other is doing. The operating system - linux handles things like file management and read and write management. So I don't think three files at once is a problem at all. Compare it to recording two items and watching a recording and using fast back - not so different. I think that Humax have simply ommited to commit the cache to disk in all circumstances while in live pause. p.s. The actual code used in open source software (which may have been modified) can be requested from Humax but this would not include other Humax code. |
|
|
|
|
|
#42 |
|
Inactive Member
Join Date: Oct 2009
Posts: 3,089
|
Quote:
But in thus the case the RAM is on the hard disk - I am not sure this is addressable by the box - It's years since I wrote interupt service routines - but I seem to remember that (on a PC) you had to use a call to write to commit the cache to disk.
Whether viewing live or viewing a recording the data must be brought into RAM (i.e. system semiconductor RAM) before it can be processed. Similarly, data must be buffered when it is retrieved from the tuner and before it is written to the disk. My contention is that the programmers who write the software for these devices (because according to DM it's not just the Humax) do not trouble themselves to write a function that will playback data within the buffer that holds data to be written to the hard drive. Instead they simply ignore the buffered data and dump the viewer back to live viewing. It's just laziness but since it's probably very rare that anyone is put out by this there's not much point in griping about it. Quote:
I don't share davemurgatroyd's fear that this would be noticable - Normally the return from these calls is very quick as the actual processing is done by another process using non maskable interupts for the minimun time necessary and most of the work is done by hardware.
I think he's correct in that if there is no function to play the 'tuner' buffer that buffer would have to be written to disk and then read back into the 'viewing' buffer. Even though the interrupt service routine would return very quickly you still have to wait for the data to move to and from the disk. Plus, you would get into serious difficulties if the pause was very short because you would have to perform this disk write/read continually for very short chunks of data.
|
|
|
|
|
|
#43 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
If it's on the hard disk, it isn't RAM.
Quote:
Whether viewing live or viewing a recording the data must be brought into RAM (i.e. system semiconductor RAM) before it can be processed.
Similarly, data must be buffered when it is retrieved from the tuner and before it is written to the disk. Quote:
My contention is that the programmers who write the software for these devices (because according to DM it's not just the Humax) do not trouble themselves to write a function that will playback data within the buffer that holds data to be written to the hard drive. Instead they simply ignore the buffered data and dump the viewer back to live viewing.
It's just laziness but since it's probably very rare that anyone is put out by this there's not much point in griping about it. I think he's correct in that if there is no function to play the 'tuner' buffer that buffer would have to be written to disk and then read back into the 'viewing' buffer. Even though the interrupt service routine would return very quickly you still have to wait for the data to move to and from the disk. Plus, you would get into serious difficulties if the pause was very short because you would have to perform this disk write/read continually for very short chunks of data. |
|
|
|
|
|
#44 |
|
Inactive Member
Join Date: Oct 2009
Posts: 3,089
|
Quote:
I know that they call it a cache - but it's ram [from the devices viewpoint] - what do you think controls a hard disk but in effect another processor.
Yes, there will be HD cache that can, because we are dealing in very large chunks of data be considered RAM. (Obviously it isn't, it is read and written in fixed length sequential chunks -even though it's composed of RAM chips - but for video it might as well be). Quote:
Well the OS - linux would - but I would also expect the application to maintain a very small buffer as well.
The application - in this case the Humax code - seems to maintain a buffer capable of holding a few seconds of data. It's when this buffer hasn't been sent to the disk (and as far as the Humax software is concerned the Linux buffer, the drive cache and the real hard drive are all the same thing), that it refuses to play the data accumulated during the pause.That points to an inability to play out data from that buffer. There really is no other explanation that fits the facts as observed. Quote:
Yes and No - Years ago with slow routines - the problem was servicing and returning from an interupt service routine without causing problems for another ISR - e.g. The clock which must be incremented at least 1/50 second intervals [I suspect more nowdays] - Disk servicing is normally from a PC's viewpoint small when compaired with repainting a screen. While a ISR has interupts disabled the box does nothing. Under 1/50 Sec humans notice nothing - thats why chips use this [or used to] (USA 1/60th) to repaint screens.
I think it's fairly safe to ignore ISR processor usage nowadays since processors that ran at well under 1 MHz were perfectly capable of handling very complex hard disks without problems. There is no reason to do any screen repainting at interrupt level.
|
|
|
|
|
|
#45 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
I see what you mean.
Yes, there will be HD cache that can, because we are dealing in very large chunks of data be considered RAM. (Obviously it isn't, it is read and written in fixed length sequential chunks -even though it's composed of RAM chips - but for video it might as well be). Quote:
The application - in this case the Humax code - seems to maintain a buffer capable of holding a few seconds of data. It's when this buffer hasn't been sent to the disk (and as far as the Humax software is concerned the Linux buffer, the drive cache and the real hard drive are all the same thing), that it refuses to play the data accumulated during the pause.
Quote:
That points to an inability to play out data from that buffer. There really is no other explanation that fits the facts as observed.
Quote:
I think it's fairly safe to ignore ISR processor usage nowadays since processors that ran at well under 1 MHz were perfectly capable of handling very complex hard disks without problems. There is no reason to do any screen repainting at interrupt level.
I must say Jepson that your posts are increasingly interesting. (i do mean this in a nice way) I hope that you find my comments complementary to the thread. |
|
|
|
|
|
#46 |
|
Inactive Member
Join Date: Oct 2009
Posts: 3,089
|
Quote:
The length of the buffer depends on the length of the buffer on the hard disk installed. [I do not know if there is a standard service routine to request this length - there never used to be.
On my 1TB dive it seems to be 96 secs+) In analysis we differ greatly, I submit that that they are unaware of the buffer and do not commit it to disk - it's the same result anyway. ![]() So we're not going to be able to agree on our speculations. Quote:
I must say Jepson that your posts are increasingly interesting. (i do mean this in a nice way) I hope that you find my comments complementary to the thread.
Yes, they are. It's always interesting to hear someone else's diagnosis of a problem because these 'blind' diagnoses are a particularly satisfying intellectual challenge.
|
|
|
|
|
|
#47 |
|
Forum Member
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
|
A further observation here is that on my Sky boxes and generic box the same problem can be observed when chase playing and FFing when you catch up to the live programme - the boxes give a message "End of programme" and if you do not wait long enough before pressing play to continue viewing you will get a short playback and then "End of programme" again - does the same thing happen on the HDR. This to me proves buffer flushing does not take place more conclusively than the live pause.
|
|
|
|
|
|
#48 |
|
Forum Member
Join Date: May 2005
Location: Redditch Worcs
Posts: 17,289
|
Quote:
A further observation here is that on my Sky boxes and generic box the same problem can be observed when chase playing and FFing when you catch up to the live programme - the boxes give a message "End of programme" and if you do not wait long enough before pressing play to continue viewing you will get a short playback and then "End of programme" again - does the same thing happen on the HDR. This to me proves buffer flushing does not take place more conclusively than the live pause.
). The foxsat-hdr at least has programmeable forward and reverse skip buttons which are incredibely usefull. For example the forward skip default is +2mins and the reverse is -15 sec. So when close to the end of the recording buffer (and when skipping adverts) using the skip button with the default settings always keeps at least a 2min margin before the buffer runs out. Sounds simple but it makes skipping ads a doddle.
|
|
|
|
|
|
#49 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
....
Ahhhh, My manual is different section 12 starts on page 66. The pause is mentioned and then as a sub-paragraph "Note: Pressing Pause while watching live TV will increase the delay from the point you have paused to the live broadcast. You will be able to use fast forward or skip-forward functions during this time. To go directly to the live broadcast press the stop button." ..... ![]() ![]() When I was looking at the manual I thought the chapter started on P.66 - Now found your quoted piece. |
|
|
|
|
|
#50 |
|
Forum Member
Join Date: Oct 2005
Location: UK
Posts: 863
|
Quote:
Too true. Where's Channel 4 HD & Five HD. To be honest I'm pi**ed off with Freesat in general, not Humax. I bought this box hoping to watch HD and all thats on offer is BBC HD for half the day and ITV HD. I'm using my V+ box more now as there are more HD channels on the basic subscription and thinking about ditching Freesat as it seems to have been forgotten!
Graham. On the subject of the Foxsat-HDR the only thing that annoys me is the pause problem and the fact that you cant record something you have just seen. If you just press record it forgets everything that was in the instant rewind buffer ![]() The slow menus are a frustration but not a big annoyance. |
|
|
|
![]() |
| Thread Tools | Search this Thread |
|
All times are GMT. The time now is 23:56.






). The foxsat-hdr at least has programmeable forward and reverse skip buttons which are incredibely usefull. For example the forward skip default is +2mins and the reverse is -15 sec. So when close to the end of the recording buffer (and when skipping adverts) using the skip button with the default settings always keeps at least a 2min margin before the buffer runs out. Sounds simple but it makes skipping ads a doddle.

