Planet Replay Forum Index Planet Replay
The Destination for ReplayTV Owners and TV Enthusiasts
Back to the home page
 
 FAQFAQ   SearchSearch   7 days of topics7 Days  30 days of topics30 Days  MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

No photo partition means no IVSmagic

 
Post new topic   Reply to topic    Planet Replay Forum Index -> IVSmagic
View previous topic :: View next topic  
Author Message
douglips
Replay junkie
Replay junkie


Joined: 19 Jan 2006
Posts: 163

PostPosted: Wed Mar 04, 2009 11:11 pm    Post subject: No photo partition means no IVSmagic Reply with quote

This post is mostly an FYI, but it may evolve into a small hack for IVSMagic.


I had a hard disk failure in my main replay TV a few months back, and after I replaced it, IVSmagic would never send a show. It always said "clockskew detected". I had no idea what that meant, so I just ignored it.

I've been a bad poopli, trying to send shows every once in a while but I never can send because of this.

So, I downloaded the IVSmagic source code and started debugging.

Here are the things I learned, some of which I didn't know before:

- the RDDNS lookup uses some kind of time based encryption, so you need to have a clock that matches the replaytv.net clocks by 40 seconds or so in order to encrypt. If you fail to do so, the RDDNS server will give you an error like "encryption expired" or something like that.

- Your replayTV is set to replaytv.net time, so it's always correct.

- IVSmagic needs to figure out the right time to use for encryption, so it creates a file on the photo partition of your master replayTV, checks the time, then deletes it.

So, if you have no photo partition, IVSMagic can't figure out the clock offset and will never be able to lookup an RDDNS value unless your computer time just happens to be set to the same time as replaytv.net.

Now, I didn't mean to set up my replayTV with no photo partition, but I guess I did when I imaged the drive. I don't think I can add one after the fact, so I was hoping to hack IVSMagic to use a different mechanism to get the clock offset.

I noticed that DVArchive knows my clock offset, it reports it at -165 seconds which would explain why I can't send a show. I unsynchronized my computer from the internet time server and set the clock back two minutes, and now RDDNS lookups work. Still haven't been able to send a show, but I'm getting other errors now, like "unable to contact remote unit".

From here, I'd like to explore the following solutions:
- Adding a photo partition to my replayTV. I don't think I will because I don't want to take it apart if it ain't broke.
- Hacking IVSMagic to use a different mechanism for clockskew detection. To this end I want to reach out to DVArchive people and see if they have any advice.
Back to top
View user's profile Send private message
hdonzis
Planet Overlord


Joined: 05 Jan 2005
Posts: 9021
Location: San Antonio, TX

PostPosted: Thu Mar 05, 2009 7:38 am    Post subject: Reply with quote

Well, I don't know about being a DVArchive people, but I have watched how DVA calculates this time skew using WireShark (because I was thinking about putting it into WiRNS) and it's a bit extreme. Pretty simply, DVA "communicates" with each ReplayTV using different time values for the encryption to "zero in" on the medium time value. So, it kind of tries different values to first at least start communicating with the ReplayTV. Then it tries to find the edges by using increased and decreased time values finding where it can successfully communicate and when it cannot (which takes a long time when it cannot communicate since it gets no response from the ReplayTV)...

It's a pretty extreme approach, and DVA can do this in background after it starts up. You may notice that the time stamps of the time offset discoveries are quite some time after DVA starts up...

WiRNS could have ability to keep a time offset per Replay. That's why I wanted to add the DVA approach, but decided that would be a bad idea for the WiRNS startup. The WiRNS approach is very logical currently and I decided it was adequate. As you posted, all your ReplayTVs get their time from the same place, so assuming that they all have about the same time is a very reasonable assumption. In the DVA log you can see that they vary somewhat, but are usually all pretty close. So, WiRNS just wants to find out the time offset between Windows and the replaytv.net clock. The assumption that the ReplayTV's time is very close to the replaytv.net clock, so if WiRNS can basically calculate the time offset from the replaytv.net clock, then it will be very close to the time offset for communicating with the ReplayTVs. As a note, in addition WiRNS also time syncs from the replaytv.net clock, just like the ReplayTVs, so its time should always be pretty close to the replaytv.net clock in the first place...

If you have the time encryption incorrect, then you cannot communicate with the ReplayTVs at all (at least for certain functions). However, as you posted, when you communicate with the RDDNS server, if you have the time encryption incorrect, the RDDNS server responds with an error and the error response contains the time used for encryption (actually, all encrypted responses have the time used for encryption). So, while encrypted responses have the encryption time in them, the trick is to get an encrypted response in the first place. Since communicating with the ReplayTVs with an incorrect time doesn't produce any reponse, only the RDDNS query will actually respond that the encryption is incorrect so that you and get the encryption time. So, what you see WiRNS do is to use one of your configured ReplayTV's ISN to perform a lookup just to communicate with the RDDNS server and calculate the appropriate time offset if necessary. That's why you sometimes see entries in the WiRNS log about ISN lookups when performing certain operations (like just browsing to the WiRNS home page when it checks the status of the RDDNS servers)...

Seeing as IVSmagic also has to be able to perform RDDNS queries, it seems like this approach may work for it as well. The creating a file on the ReplayTV approach is pretty clever and certainly a simple way to calculate the time offset per ReplayTV, more like DVArchive (although, much faster than the DVA approach). So, it may be quite easy to use the RDDNS query to calculate the time offset as WiRNS does to take care of this problem. I guess it's just not one of the things that Bob and Ryan discussed back in the day...

I have to assume that IVSmagic uses the published encryption/decryption alogrithms. The decrypt function already has in it to obtain the encryption time from an RDDNS query. You can see in the TWIKI for the decrypt() funtion that it takes a pointer to a time variable for it to store the encrypted time, and all you have to do is to add in the encrypt() function to add the time offset to the time() value within that function by calculating the time offset by subtracting the encrypted time from decrypt() from the current time when you call decrypt()...

Henry
_________________
Here's my Poop (I know that's the old Poopli, but I like it that way!)
Back to top
View user's profile Send private message
douglips
Replay junkie
Replay junkie


Joined: 19 Jan 2006
Posts: 163

PostPosted: Mon Mar 09, 2009 9:21 pm    Post subject: Reply with quote

Thanks, that's some good info! I'll have to see when the hacking bug bites me again.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Planet Replay Forum Index -> IVSmagic All times are GMT - 8 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Planet Replay topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group