I just noticed that one of my ReplayTV's hasn't had it's guide updated since Jan 6. The other one, and the local guide, are up-to-date. When I click 'refresh' to manually refresh it, I see a 'php-cgi.exe' process for the request, but then it starts using 100% of the CPU and after a 2-3 minutes, it goes away - but the guide is not updated. Refreshing the other replay takes only 10 seconds or so.

I've tried deleting the replay and re-adding it, but I'm still having this problem. I tried optimizing and rebuilding the database, and neither helped.

There's nothing interesting in any of the logs. I can see the 'replay guide update of *jlv* succeeded' in the status log for my manual refreshes of the working replay, but no message at all for the refreshes of the replay it isn't updating. The last successful update message was in the scheduler log -- for Jan 6. There's nothing in the error log.

I am able to download the guide from this ReplayTV just fine from DVA and the Poopli Updater -- it's just IVSm that is having the problem.

Any ideas?

Quote:

UPDATE: Feb-24-2009:
The patch for this is included in a post below.
Since it's not available elsewhere, I've made a fixed version of refresh_replay_guide.php available for download.
Save the downloaded file in the include directory of IVSmagic, which defaults to C:\Program Files\IVSmagic\IVSm\include

Last edited by jlv on Tue Feb 24, 2009 10:08 am; edited 3 times in total

That's just basically saying that Apache aborted the request because it took too long. The IVSm-httpd.conf has the stock Apache timeout of 300 secs. The first of these in the log is dated Jan 6, of course.

I did finish receiving a show on that unit around the 5th, and the scheduler logs indicate the last successful guide update was at 9:07am on the 6th, so I don't think that show could have (somehow) been the cause.

I take that back -- I had a received show complete inbetween those two updates. And when I look at the guide data IVSm has inserted into the database, it ends just before that show.

Looking at the guide snapshot with the command line tools shows me that the show header has bogus-looking values for actors, guests, and directors. With that in hand, I started debugging refresh_replay_guide.php and found that it is going into an infinite loop at line 293, which is where it is trying to look for the title+episode+description. Changing that line from:

After debugging this further, I see that this loop is there because someone was trying to work around a bug in splitting apart the description block of a FixedProgramRecord. The description block has two optional headers: one of 4 bytes if the has_parts bit (0x40) is set in the ProgramFlag, and one of 8 bytes if the is_movie bit (0x20) is set in the ProgramFlag.

The purpose of this 'for' that was becoming an infinite loop for me looks to try to guess the offset into the description block. I didn't understand why that was there, when the two bits of the ProgramFlag were already split out. However, in debugging this, I found one show whose ProgramFlag was 0x80000020. is_movie should be true, and has_parts should be false. However, the $part_flag variable set at line 280 was TRUE. I found that every time the high bit was set in ProgramFlag, the values of these two variables would be wrong.

I suspect that there is some weirdness with $_program_flags having the high-bit set -- perhaps signed/unsigned. I know that when I included this debug code:

So, it appears that PHP is doing the wrong thing for logical operations on (unsigned int) numbers with the high-bit set.

Since this code doesn't use the bits in the high byte of ProgramFlag, I changed it to only extract the lower 3 bytes of it. And since the bit tests now work correctly, I removed the broken loop and replaced it with direct adjustments on the offset into the description block. This is my final patch:

However, in debugging this, I found one show whose ProgramFlag was 0x80000020. is_movie should be true, and has_parts should be false. However, the $part_flag variable set at line 280 was TRUE. I found that every time the high bit was set in ProgramFlag, the values of these two variables would be wrong.

I suspect that there is some weirdness with $_program_flags having the high-bit set -- perhaps signed/unsigned. I know that when I included this debug code:

So, it appears that PHP is doing the wrong thing for logical operations on (unsigned int) numbers with the high-bit set.

It's probably using signed integers for its logical operations. Which means that it two's complements the signed integer, 0x80000020, to 0x7FFFFFE0, which then has both the parts bit and movie bit on. While this isn't very common, it makes things like anding -1 with 1 come out correctly. Basically it performs logical operations on the absolute value of the signed integer so as not to take the signed value into account (that logical operations come out the same whether the interger is positive or negative)...

Good thing that IVSmagic doesn't care about the movie subratings!

What I find very eerie about your findings is that extract_rtv, which is very old, had very similar code in it (in C) for skipping over the movie info and parts info:

ascii48bit2dec() returns the result of bcadd(), which is a string. When that string is used in the logical operation, it's being converted to a signed integer -- but it's value is capped at MAX_INT (2^31-1).

Well, without your printing logically anding the string value it wouldn't have been clear that it was turning that into a positive all ones value (such at all bits would have been true and you would have seen a whole bunch more things in IVSmagic happen). When you print logically anding the numeric value, it shows as I expect as a negative of the two-complement value...

That'll teach someone to use string as numerics instead of integers! Maybe a string value is defaulted fitting in a 32 bit value (like atoi()) such that it is only allowed to be 2147483647 to -2147483648 on the logical operations. But, on the arithmetic operation, it allowed it to fit into a larger size integer...

That's good that you were able to figure out the solution without losing any bits of information!

Henry_________________Here's my Poop (I know that's the old Poopli, but I like it that way!)

I just came here to the forums to see if anyone else was having the problem I'm seeing -- that guide for one of my Replay's won't refresh, and that IVSmagic uses 100% CPU while trying to refresh it.

I'm glad to see someone not only had the problem, but also posted the fix.

It's sad that it was me, and that (1) I'd forgotten about doing this and (2) I'd lost the fix.

Sometime back in December when I was installing WiRNS, I did an 'update' on IVSmagic. I don't know why I did. What the update managed to do was replace the fixed code with the release (buggy) version. At the time, I only thought it deleted piles of debugging code I'd put in various places, so I didn't think twice of it. I didn't remember fixing any code.*

I just checked IVSMagic out of the CVS repository and will get this fix checked in, so this doesn't happen to me (or anyone else) again.

(Ah, I gotta get write access...)

* (I have a memory-loss problem that impacts the establishment of medium- and long-term memories. Needless to say, I've had this problem for as long as I can remember...
Seriously, it causes me no end of frustration, because if I don't work on something for 2-3 days, I totally forget about it.)