• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Insufficient disk space ... for what?

af123 said:
So... the question now is, do people want the web interface to show the same number as the on-TV interface either always, or by default, or via an option?
Click to expand...

If it is possible to match the on-TV-screen number, I'd always vote for that to be the most prominent number displayed in webif - because when the on-TV-screen number hits 0, recording stops - so awareness of proximity to that 0 is vital for people who, despite all good advice, are running their HDR to full capacity.

However if it's impossible to get an exact match at all times, then to have a free space number in webif which is always lower than the on-TV number is preferable, as it provides a warning in advance.

The worst case is ever having a free space number on webif which is higher than on-TV - as it implies recording space potential that isn't really available - and that might, sometimes, lead to unexpected failed recordings and annoyance.

Is it yet totally clear how the 'available space' number in the on-TV Media view is calculated? It is presumably the same method that delivers the number to the 'Data Storage' page in the 'Menu'.

Where does the streamer file for iPlayer reside? Does it affect calculations?

I'm still puzzled as to why the disparity between on-TV and webif varies - one day the difference here was 2.89 GB, next day it was 7.1 GB. Could this be due to the Tsr buffer somehow?

However, today, the 'free space' figures here are:
HDR Box A ... on-TV 'Data Storage' page shows 584.8GB .... webif shows 587.13 GiB ... difference = 2.33

HDR Box B ... on-TV 'Data Storage' page shows 34.0GB .... webif shows 36.42 GiB ... difference = 2.42
 
I think I'm getting there. Try the version of webif I've just uploaded.
The iPlayer streamer file is on a different partition so doesn't affect the calculations.
The difference varies because the size of the Tsr buffer varies.
 
af123 said:
I think I'm getting there. Try the version of webif I've just uploaded.
Click to expand...

Thank you very muchly... 1.0.14-2 downloaded.

Definitely getting there ... in fact, at first look ... actually there! :D

Latest results:

HDR Box A ... on-TV 'Data Storage' page shows 584.9 GB .... webif shows 584.94 GiB ... difference = 0

HDR Box B ... on-TV 'Data Storage' page shows 33.7 GB .... webif shows 33.75 GiB ... difference = 0

To misquote Professor Higgins, "By Jove, I think he's got it!"

Excellent.
 
Mine, with a 2TB drive, matches too! I doubt it's right on a HD Fox yet but I can look at this later.
 
Humax are definitely using the Reserved Size to hide the difference between the disk manufacturer's size in GB and the free space in GiB. Here's the screen from my unit with a 2TB disk.

IMG_0494.JPG

Like your 1TB disk example, the top three numbers add up to 20 somethings more than the total, 2020 in this case.

2TB is 1862.6 GiB - my video partition is actually 1851.4GiB
2000 - 1851.4 = 148.6 which, as with the 1TB example, is 20GiB less than the Reserved Size reported on screen.
 
I have always regarded the "total size" figure as artificial, but I don't understand where the figure comes from with your non-standard 2TB drive (I can't imagine it is programmed into the Humax firmware).
 
Black Hole said:
I have always regarded the "total size" figure as artificial, but I don't understand where the figure comes from with your non-standard 2TB drive (I can't imagine it is programmed into the Humax firmware).
Click to expand...
I'd speculate that total size is read directly from the drive and converted into GB (/1000^3). A 1TB drive reports, for example: User Capacity: 1,000,204,886,016 bytes. That includes some spare sectors but rounds down to 1000GB.

Having done that, they appear to create an artificial reserved figure as <drive reported size in GB> - <recording partition size in GiB> + 20

20GiB is the amount of space reserved (but not always in use) for the TSR buffer (same size on a HD too btw).

The Available Size shown is: <free space on recording partition> - (20GiB - <current size of TSR buffer)
The Used Size shown is:<used space on recording partition> + (20GiB - <current size of TSR buffer)

The extra 20GB shouldn't be included in the reserved figure but is and so the sum of the first three values is always 20 more than the last, at least on DelftBlue's two 1TB boxes and my 2TB & 5ooMB ones, and on my HD with a small-ish disk (can't remember the exact size but it follows the same rules).
 
Maybe, but it still strikes me as a coincidence. It would be interesting to get a report from somebody who's fitted a (say) 750GB drive.
 
Howdy... Am resurrecting this elderly thread because it has a lot of the relevant info in it.
I have occasionally been seeing "free" disk space in Webif which is precisely 20GB bigger than I expected (and than the TV shows).
I've traced this to system.class and diskspace.jim.
I suspect there's a gotcha in system.class - when Tsr/0.ts isn't present, tsrbuf is set to 0, but when the file is present it gets set to 20GB's worth. Thus, if the file is missing, diskspace.jim duly subtracts 0 from the available free blocks value.
Code: 
      if {[file exists "$tsrdir/0.ts"]} {
              set tsrbuf 21474836480
              lassign [exec du -ks $tsrdir] tsrused
              set tsrused $($tsrused * 1024)
      } else {
              set tsrbuf 0
              set tsrused 0
      }
I'm just guessing about the next bit: perhaps the tsr buffer gets deleted sometimes, e.g. when someone reverses into it and hits record. I know that we did just that tonight, shortly before the free space showed up as wrong. I didn't get a chance to investigate while it was wrong because a few minutes later it corrected itself :)

Anyway, one fix would be to always set tsrbuf to 20GB and just pick up tsrused from the file if it exists... This might be wrong though?

EDIT: I forgot to state I'm on webif version 1.2.3-5
 
Updates...
Firstly, I have now verified that recording from part of the TSR buffer does indeed cause it to be deleted, which triggers this buglet.
Secondly, I'm proposing this tiny tweak which seems to fix the problem on my HDR box and probably works on HD boxes too (btw, is there a better place to post patches?):
Code: 
--- system.class.orig
+++ system.class
@@ -304,7 +304,7 @@
                HD { set tsrdir "/media/drive1/.tsr" }
        }

-       if {[file exists "$tsrdir/0.ts"]} {
+       if {[file exists "$tsrdir"]} {
                set tsrbuf 21474836480
                lassign [exec du -ks $tsrdir] tsrused
                set tsrused $($tsrused * 1024)
What do you reckon af123?
 
Slightly different fix will appear in next update:
Code: 
  switch [system model] {
    HDR {
      set tsrdir "/mnt/hd2/Tsr"
      set tsrok [file isdirectory "$tsrdir"]
    }
    HD {
      set tsrdir "/media/drive1/.tsr"
      set tsrok [file exists "$tsrdir/0.ts"]
    }
  }

  if {$tsrok} {
    set tsrbuf 21474836480
    lassign [exec du -ks $tsrdir] tsrused
    set tsrused $($tsrused * 1024)
  } else {
    set tsrbuf 0
    set tsrused 0
  }

Can't get it to paste properly : (
 
Last edited:
You must log in or register to reply here.
Back
Top