DS Forums

 
 

Foxsat-HDR Issues


Reply
Thread Tools Search this Thread
Old 01-08-2010, 19:20
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
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
Noted. The spike protected mains block I use has a switch which I will use.

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
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."

If they have modified the manual it's an indication that we are not going to get it fixed
REPASSAC is offline   Reply With Quote
Please sign in or register to remove this advertisement.
Old 01-08-2010, 20:09
Jepson
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.
Jepson is offline   Reply With Quote
Old 01-08-2010, 20:26
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
The current manual can be found at http://www.humaxdigital.com/global/p...0-0618_low.pdf.

400GB ???
REPASSAC is offline   Reply With Quote
Old 01-08-2010, 22:21
tgabber
Forum Member
 
Join Date: Feb 2004
Location: Sunny France (sometimes)
Posts: 1,017
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.
tgabber is offline   Reply With Quote
Old 01-08-2010, 23:42
davemurgatroyd
Forum Member
 
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
^^^ 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.
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.
davemurgatroyd is offline   Reply With Quote
Old 02-08-2010, 09:35
Jepson
Inactive Member
 
Join Date: Oct 2009
Posts: 3,089
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.
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.
Jepson is offline   Reply With Quote
Old 02-08-2010, 10:03
REPASSAC
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.
REPASSAC is offline   Reply With Quote
Old 02-08-2010, 10:26
Badvok
Guest
 
Join Date: Apr 2004
Posts: 957
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.
Had a repeat of this on Saturday for the F1 qualifying. My daughter has a riding lesson at 2:00pm so I always miss Q3
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!
Badvok is offline   Reply With Quote
Old 02-08-2010, 10:43
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
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.
Yes no problem if it's on. I tried setting Power Saving in standby to OFF and a timer for 00:01. After power OFF after a short pause the clock showed 00:00 and a min later 00:01 but nothing happened.

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.
REPASSAC is offline   Reply With Quote
Old 02-08-2010, 11:47
davemurgatroyd
Forum Member
 
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
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.
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.
davemurgatroyd is offline   Reply With Quote
Old 02-08-2010, 12:47
Jepson
Inactive Member
 
Join Date: Oct 2009
Posts: 3,089
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.
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.

We can verify that by checking to see if an HD programme will correctly handle a smaller pause than an SD one.
Jepson is offline   Reply With Quote
Old 02-08-2010, 14:10
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
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.
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.
REPASSAC is offline   Reply With Quote
Old 02-08-2010, 14:52
Badvok
Guest
 
Join Date: Apr 2004
Posts: 957
But in thus the case the RAM is on the hard disk -
Yes, I think that is exactly what the novice programmers who wrote this software are doing - it is just not the correct way it should have been done.
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.
Badvok is offline   Reply With Quote
Old 02-08-2010, 15:32
davemurgatroyd
Forum Member
 
Join Date: Mar 2002
Location: Oxford
Posts: 12,689
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.
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
davemurgatroyd is offline   Reply With Quote
Old 02-08-2010, 15:42
grahamlthompson
Forum Member
 
Join Date: May 2005
Location: Redditch Worcs
Posts: 17,288
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
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.
grahamlthompson is offline   Reply With Quote
Old 02-08-2010, 16:34
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
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
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.
While I am not up to date on these things I do remember that PC's had the clearing buffering problem when disk RAM first came up & MS had to additionally flush the cache on shutdown and provide a means to disable write caching in their opening systems.

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.
REPASSAC is offline   Reply With Quote
Old 02-08-2010, 17:39
Jepson
Inactive Member
 
Join Date: Oct 2009
Posts: 3,089
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.
If it's on the hard disk, it isn't RAM.

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.

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.
Jepson is offline   Reply With Quote
Old 02-08-2010, 18:18
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
If it's on the hard disk, it isn't RAM.
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.

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.
Well the OS - linux would - but I would also expect the application to maintain a very small buffer as well.

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.
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.
REPASSAC is offline   Reply With Quote
Old 02-08-2010, 18:49
Jepson
Inactive Member
 
Join Date: Oct 2009
Posts: 3,089
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.
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).

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.

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.
Jepson is offline   Reply With Quote
Old 02-08-2010, 19:50
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
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).
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.

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.
On my 1TB dive it seems to be 96 secs+)

That points to an inability to play out data from that buffer. There really is no other explanation that fits the facts as observed.
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.

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.
Well yes - while I done exactly that in the past - To overcome a omission in an operating system and repaint a screen in under 1/50 sec- The point was to make a comparison of the amount of CPU oprtions required. I think that you also accept my assertion that to do the hard required disk operations would not be a problem.

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.
REPASSAC is offline   Reply With Quote
Old 02-08-2010, 20:15
Jepson
Inactive Member
 
Join Date: Oct 2009
Posts: 3,089
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.
I think the problem with this discussion is that we have both built up pictures of the logical structure of the Humax hardware and software, based upon our particular previous experiences and the don't match.

So we're not going to be able to agree on our speculations.

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.
Jepson is offline   Reply With Quote
Old 02-08-2010, 21:35
davemurgatroyd
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.
davemurgatroyd is offline   Reply With Quote
Old 03-08-2010, 23:24
grahamlthompson
Forum Member
 
Join Date: May 2005
Location: Redditch Worcs
Posts: 17,288
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.
Not seen anything like this in chase play (I don't use the timeslip buffer for the reasons dicussed in this thread ). 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.
grahamlthompson is offline   Reply With Quote
Old 04-08-2010, 16:47
REPASSAC
Forum Member
 
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
....

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."

.....
oooops Sorry Geoff P. & Humax
When I was looking at the manual I thought the chapter started on P.66 - Now found your quoted piece.
REPASSAC is offline   Reply With Quote
Old 10-08-2010, 20:36
snapey999
Forum Member
 
Join Date: Oct 2005
Location: UK
Posts: 863
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.
I have heard that the reason for no C4 and C5 HD is because they have to be encrypted because they are on a european transponder and not a uk focused transponder, If Sky moved or were forced to move some of their encrypted channels off the UK only transponder to the european ones we could almost instantly have some more HD channels.

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.
snapey999 is offline   Reply With Quote
 
Reply




 
Forum Jump


All times are GMT. The time now is 10:50.