Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-1027

Billing graphs (Accurate,historical,transfer) use incorrect to value as default

Details

    • Bug
    • Resolution: Fixed
    • Critical
    • None
    • None
    • Billing
    • Linux 2.6.32-431 x86_64
      Observium SVN rev 5839


    Description

      The graphs on the Billing portion fail to render, due to pulling incorrect information. Attempting to load the 'Accurate graph' for example, the img url reports an internal server 500 error due to resource not found.

      I tried to load the file/image directly, with debug, and the SQL statement is showing an incorrect <= FROM_UNIXTIMESTAMP value. The value is that of 1414817999 which converts to Jun 26th 1974. There are obviously, no records in mysql earlier than Jun 26th 1974.

      The full debug page from trying to load the image is as follows:

      > $vars
      /opt/observium/includes/common.inc.php:193SELECT * FROM `entity_permissions` WHERE `user_id` = '1'
      string(56)
      /opt/observium/includes/common.inc.php:193SELECT `value` FROM `users_prefs` WHERE `user_id` = '1' AND `pref` = 'atom_key'
      string(79)
      /opt/observium/includes/common.inc.php:193SELECT * from `bills` WHERE `bill_id`= '1' LIMIT 1
      string(50)
      /opt/observium/includes/common.inc.php:193SELECT count(`delta`) FROM `bill_data` WHERE `bill_id` = '1' AND `timestamp` >= FROM_UNIXTIME( '1412139600' ) AND `timestamp` <= FROM_UNIXTIME( '1414817999' )
      string(158)
      /opt/observium/includes/common.inc.php:193SELECT *, UNIX_TIMESTAMP(timestamp) AS formatted_date FROM bill_data WHERE bill_id = '1' AND `timestamp` >= FROM_UNIXTIME( '1412139600' ) AND `timestamp` <= FROM_UNIXTIME( '1414817999' ) ORDER BY timestamp ASC
      string(209)
      JpGraph Error: 25082 Illegal sizes specified for width or height when creating an image, (width=0, height=0)

      When using the statement SELECT *, UNIX_TIMESTAMP(timestamp) AS formatted_date FROM bill_data WHERE bill_id = '1' AND `timestamp` >= FROM_UNIXTIME( '1412139600' ) AND `timestamp` <= FROM_UNIXTIME( '1414817999' ) ORDER BY timestamp ASC` in mysql cli, 0 rows are returned.

      Changing the last `FROM_UNIXTIMESTAMP` to the current unix timestamp (ex, using date+%s which returns 1412275323), the SQL statement returns 50 rows.

      Changing the URL above, to reflect the new 1412275323 value, the graph image still fails to render. The only difference in the output from above, is the new value reflected in the SQL statement.

      Attachments

        Activity

          [OBS-1027] Billing graphs (Accurate,historical,transfer) use incorrect to value as default

          Yeah, they changed quite a lot. The original graphing code here was written in 2005, so was written in a pretty old version.

          One day we'll replace it all with something prettier, but for now, you need 3.0.7

          adama Adam Armstrong added a comment - Yeah, they changed quite a lot. The original graphing code here was written in 2005, so was written in a pretty old version. One day we'll replace it all with something prettier, but for now, you need 3.0.7
          PenguinCoder Chris Williams added a comment - - edited

          Adam,

          It seems this is a bug with JPgraph, and not in Observium. Using jpgraph 3.5.0b1 (latest from jpgraph.net/download), I cannot get any of the accurate/historical/transfer graphs to work. Downgrading jpgraph to version 3.0.7, solves this issue. That is, the graphs render as expected.

          PenguinCoder Chris Williams added a comment - - edited Adam, It seems this is a bug with JPgraph, and not in Observium. Using jpgraph 3.5.0b1 (latest from jpgraph.net/download), I cannot get any of the accurate/historical/transfer graphs to work. Downgrading jpgraph to version 3.0.7, solves this issue. That is, the graphs render as expected.
          adama Adam Armstrong added a comment - - edited

          You're the first person to ever report this issue.

          This usually means you're not reporting a bug, but something strange about your local install.

          adama Adam Armstrong added a comment - - edited You're the first person to ever report this issue. This usually means you're not reporting a bug, but something strange about your local install.

          People

            codekiller Dennis de Houx
            PenguinCoder Chris Williams
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: