need slice files

[aram1s]

Hi all,
I started looking through the slice files that are available on the net and I noticed that they are really not all that complicated. I need some that I have a point of reference for though. Can anyone get me slice files for one of the public systems like DirecTV or Dish Network (something that is easily matched against publically available data)?

Also, does anyone know where the expiration date for the data is stored and how to update that date? I am working under 1.3 right now so the info for 1.3 would be easiest for me.

Thanks,
A

[surgeon]

Originally posted by aram1s
Can anyone get me slice files for one of the public systems like DirecTV or Dish Network (something that is easily matched against publically available data)?
Thanks,
A

I can provide you with all the DTV slice files you'd want, but all my systems are currently @ v2.0.1. I don't know if the slice files themselves are any different between versions or not? Let me know if you want 'em...

[mrblack51]

where will i find the slices on the dtivo? i have ethernet running on my sa, and would like to try using the dtivo data on the sa. i plan on putting together a set of instructions if i am successful.

[surgeon]

Originally posted by mrblack51
where will i find the slices on the dtivo? i have ethernet running on my sa, and would like to try using the dtivo data on the sa. i plan on putting together a set of instructions if i am successful.

The slice files are created in "/var/packages/" and deleted once they are used, so you'll have to start a call and wait for the download to complete and for the TiVo to start 'processing' the files. That's when you can copy them to another dir for examination...

[aram1s]

surgeon - Yes, that would be great. I am pretty sure that the slice files have not changed, and for something this important I could probably update to 2.0 without any problems :) All I have to do is let mt tivo make the call and it should take the update, but I would rather do that last. Do you have a place I can grab them from, or do I need to set one up for you?

A

[surgeon]

Originally posted by aram1s
surgeon - Yes, that would be great. I am pretty sure that the slice files have not changed, and for something this important I could probably update to 2.0 without any problems :) All I have to do is let mt tivo make the call and it should take the update, but I would rather do that last. Do you have a place I can grab them from, or do I need to set one up for you?

A

I'll need a place to send 'em... Don't know if it will compress or not but on the TiVo it's almost 10MB. You can email me with the url if you like...

[Tictoc]

Hi surgeon,

How did you get the slice files? Did you copy it manually everytime it downloaded the guide, or did you have more convenient method?

Thanks for sharing.

[surgeon]

Originally posted by Tictoc
Hi surgeon,

How did you get the slice files? Did you copy it manually everytime it downloaded the guide, or did you have more convenient method?

Thanks for sharing.

Nothing fancy... I just start a daily call and wait until the download completes & it starts un-slicing the files, then I copy them to another dir via my TiVoNet's Telnet connection...

[Tictoc]

I was hoping you have another way.

Thanks anyway :)

[stryder]

Has anyone seen a script on their Tivo called AsciiSlice.itcl ? I bet it would explain the slice file format, well the ascii version of it in great detail.

[iceberg]

I've read but haven't tested that you can create a hard link to a slice file as it's being downloaded... When the file is deleted after the slice is done, it won't delete the linked file. Again I haven't tested it but...

ln SliceFile SliceFile.bak

after the system deletes SliceFile, SliceFile.bak should still exist. Let me know if this helps.

[aram1s]

surgeon: I set up the FTP for you. Check your email for the details.

A

[TheDoctor]

This might be of some help. It is a partial decode of the PROGRAM record format. Field types are indicated by a key value followed by field length or interger value. Not all fields are mandatory. The this example the value of unprintable characters is shown in '[]' brackets.

From movie==========
E[19]Blast From the Past
'title (len 19)
[128][100]A man who grew up inside a nuclear fallout shelter is sent out for supplies for him and his parents.
'description len(100)
Q[7]English
'language (len 7)
\[3]
'mpaa
x[10] 'advisory
x[1] 'advisory
[125][14]Fraser[124]|Brendan
'actor (len 14)
[133][11]Wilson[124]|Hugh
'director(len 11)
[141][12]Harlin[124]|Renny
'Executive Produceder
[137][13]Perkash[124]|Sunil
'Produceder
i[13]United States
'country of origin (len 13)

From TV Episode===============(other fields same as above)
A[13]EP0018260001´ 'TmsID???
'EP001826 is used by 'Get Smart' shows
'0001' seems to be some type of show number. I am
not sure that this is the producers episode number.
'MV' denotes movies, 'SH' a non-episode show.
u[7]Mr. Big
'Episode title

The station info follows a similar format.

What I have not figured out is where the station/showtimes are stored.

Hope this is of some help.

[surgeon]

Originally posted by aram1s
surgeon: I set up the FTP for you. Check your email for the details.

A

Should have some samples there now...

[aram1s]

Got the files - thanks!

TheDoctor: The schedule for each channel is stored in the tivo as a date and a slot number. So the first show of the day should be 0001 then 0002, etc. I'll hopefully have more info after I get a chance to actually look at the slice files when (if?) I get some free time.

A

[aram1s]

Hrm...

Not to be a party pooper or anything, but I think that perhaps we might be better off taking this into a private email-type thread. I spent 10 minutes looking at the slice files and already I can see that it is not going to take a genius to rip these things to shreads. In the 10 ins I have looked I have picked out record formats, record size markers, field descriptors and all kinds of nasty stuff. Given that all of this is wide open, and I believe that most of us want tivo to continue to have a revenue stream, to continue along this path out in the open might cause tivo some big problems.

I will leave it up to all of you, as I have joined in sort of after-the-fact, but while I do not mind giving people detailed step-by-step instruction on the use of ExtractStream and ZapStream and things like that, we are already close, with minimal work, to being able to create our own slice files.

With that said, I am going to write a program to help me out with the decoding of the slice files. Doing it by hand will be way too much work.

A

[surgeon]

Originally posted by aram1s
Hrm...

Not to be a party pooper or anything, but I think that perhaps we might be better off taking this into a private email-type thread.
<snip>
Given that all of this is wide open, and I believe that most of us want tivo to continue to have a revenue stream, to continue along this path out in the open might cause tivo some big problems.

A

I have been an avid supporter of TiVo since day-one, and now own 4 units, 3 of which have lifetime subs, and have 'sold' many more than that to friends and relatives by explaining the wonders of TiVo, which seems to be beyond the abilities of most retail sales people.

But one of the things that irks me to no end is that they offer no discount subscriptions for those of us that own multiple units. Even highway bandits like local cable companies and Direct-TV don't gouge their customers by charging full price for having a second TV in the bedroom or a third in the basement.

And I also worry if TiVo might not already have some BIG problems -- ie: running out of money, big-time stock suits, and M$ entering the arena -- and wonder if they will be able to 'weather-the-storm' for the next several months... I don't want to be a pesimist, but I wonder if all the sale/clearance prices on units might have something to do with the retail market possibly seeing the same thing? (I *hope* not! I *do* want TiVo to live-long-and-prosper!)

That said, I think finding alternative sources for guide data might be a priority even if we hold it back from the public-at-large until the final results are in...

Maybe Vadim would be interested in setting up a 'private' forum for this much-needed research? I applaud his efforts in creating these forums as an alternative to the TiVo sponsored ones found elsewhere...

If it is decided to take this off-line, you know how to reach me, and I'll help in any way I can...

[iceberg]

I have followed most of the threads on this forum, and I can't decide which is the best way to go... Should I focus my efforts on working with slice files, or should I work in the direction of the jpag scripts? I have my Tivo all networked (ppp/serial) and should have the serviceState taken care of soon. Now all thats left is getting the guide data into it. What do people think is the proper way to proceed?

[stryder]

I haven't decided which would be the better way to proceed. The slice files have the benefit of being the native method of getting guide data into the tivo. Now the scripts are easier to read, but I am not sure that they can accompllish the complete job to get the tivo to acknoledge that it has new guide data.

[TheDoctor]

I tend to agree with aram1s, that we might need to take this off line.

I have identified shema record types 3,4,5,6 and I believe 7 in the slice files. I have mostly decoded 3(program), 5(station),
6(stationday). The type 7(Showing) object appear to use a diffrent header format....

There appear to be fields that the JPAQ style scripts are currently not loading and I think it would be easirer to use the slice format.

With either format I think it will take some heavy CPU power to process large multi-day guides like direct tv, in order to supply ALL fields, with accurate times.

I am trying to decide if it is better to try finish decoding/recreating the slice files or to build a standalone pc application to control recording/playback. I could perform more complex scheduling, and load between tivo boxes.

[iceberg]

I'm in for either on or off line. I'm just getting started, but this is my project at home at the moment. I can probably dedicate an hour or so a day on it. I'm just learning the tivosh, but have done shell script, c, perl, etc programming in the past.

[stryder]

I have all of the schema files that define each one of these things if you would like to have access to them. I got them off of a virgin backup that a member here so kindly gave me access to.

[aram1s]

stryder:

Hell yes!!!! Either private msg them or post them or even email them to me.

I have (just barely) started writing a program in Delphi to decode the slice files, only because the damned things are too big to do through by hand :) I suspect that with the push to get some projects done this week at work I am not going to have a ton of time to be working on the slice files before next week again, although I am certainly going to try.

As for scripts vs slice, I am not sure that we have all of the information we need to do this by scripts, so Hobson's choice is to work on the slice files.

As for processing power, it is not that big of a deal. Even if it takes hours to do (it won't), you only need to do it every day or two.

If we could eventually get it to the point where it could be done in tcl (i really am learning to hate tcl) you could set up a very low priority (nice+10) job on your tivo to read in the data a little at a time and process it as it has the chance.

As for tivo going out of business... Well, I certainly hope it does not happen and I definitely do not want to help it happen, but I agree that it would be a good idea for us to be ready in case it does. I know that tivolutionary has said that tivo will release the info we need to do it if they go under, but having watched many technology companies go under in the last year, I know that investors will often step in and stop companies from doing what they want to do at the end, especially if there is still the potential to sell off the IP of the company.

A

[sir_lunatic]

Well I am back but not for long.

Anyways, been reading through the threads, saw this one and figured I should put my two cents in.

First: Welcome on board to the new guys/gals. In particularly to "aram1s", looks like he will be a good addition to the effort.

Second: If it wasn't to the open discussion on this matter, graciously provided by "vadim"; thank you; "aram1s" and the others would not have been able to join in the reindeer games.

Reverse engineering the slice files is a necessity and we have all known this from the beginning, whether we use their format or jPags's to create ours.

Also once something is released to the public to use to create (our) slice files, it would be public knowledge.

I say keep it in open forum and allow others to join in freely. That was the purpose of this board to begin with.

Not to say, what goes on elsewhere......

[aram1s]

OK - need some help here...

Here is some of what I have gotten and what is stumping me...

Slice files:
First byte is 03 - Might be a version number
Then come the records...
4 bytes: record size
the next few bytes are confusing me - i will come back to them, but here is where my problem lies...
Then come a bunch of fields, the order of which may or may not matter. Some are fixed length, others have a length byte (specifically the PStrings, which are pascal strings, a 1 byte length followed by the data, non-zero terminated)...

41 - Show type(PString) first 2 bytes are type type, next 5 a numeric (show #?) next four are also numeric (showing?)
45 - Guide Desc(Pstring)
4D - Description'(Pstring) The long description
51 - Language(Pstring)
58 - Unknown - 7 bytes
69 - Country(Pstring)
7D - Starring (PString) - There are usually multiple of these

There are many others too of course. Numbers seem to be MSB first (ie record length) and all strings seem so far to be pstrings

Now, back to my problem...
After the record size comes either 01 03 or 01 04 followed by 3 or 4 bytes (no relation to the 03 or 04) followed by what I assume is the record type as 1 byte. The question is: How do I determine whether there are 3 or 4 bytes of data before the record type?

Thanks,
A

[stryder]

Here are all of the schema files. I believe the ones you will be most interested in are :

Showing.schema
StationDay.schema
Station.schema
Lineup.schema
HeadendDay.schema
ShowingDerived.schema

Now there may be others of interest as well.

[iceberg]

Last night, I finished getting the nagz out of my (never called home) TiVo. I modified the comp-in.tcl (http://pvrhack.sonnik.com/tivo/download.asp) file to allow for manual addition of cable stations (I have direct cable into RF). Am I duplicating effort? Is there already a way to add a channel lineup in a format similar to:
2 WGHB
3 LOCAL
...
and have that populate the channel lineup. If not I'm going to just convert the applicable section of comp-in.tcl into a subroutine and feed it the lineup.

Now that I'm going to be up and running in short order. What needs to be done on the slice/jpag front to get that moving forward? Where is everyone at? Are people thinking just self-creating .slice files on another machine and imputing them the TiVo way (dbload was it?) is the best way? I have an old Compaq pentium150 laptop running pppd connected to my TiVo, so I could have that parse the tvguide data if necessary and spoon feed it to my tivo.

Let me know what I can work on to help and I'm there.

[TheDoctor]

This is going to be messy, but here goes. I have been working at decoding one movie all the way through the slice file. There are several record types involved.

Most of the discussion in this forum seems to be focused around the type 3 (program) and type 4 (series) records. They are the most obvious because they contain text descriptions. There is one unique instance of each in the database no matter how many stations or showing occur. However they contain no channel or show time information. Show times are stored in the type 7(showing) records. Type 7 records have start-time and duration, as well as references to the type 3(program) record and type 5 (station) records. The sequence of shows on a given channel are stored in the type 6(StationDay) records.

Attached is a breakdown of the linkages and field decodes of a single movie for type 3,5,6,7. A type 4 series object does exist for this movie, but I have not bothered decoding it, as I don’t think it is mandatory. I believe one of my previous postings contains series specific data such as episode names…
(Briefly, A[13]EP0018260001´ 'TmsID
'EP001826 is get smart
u[7]Mr. Big
'Episode title
)


In addition to the decode I have included the raw record in a bracketed decimal format. In some cases the ascii character will appear in addition to or in place of a decimal value. It should be noted that type 7 records may have a different header format depending on their appearance as a separate record or as a sub-record of a type 6 record. Additional bytes may appear at the end of the records.

[TheDoctor]

My agreement that this might be easier to handle in an e-mail exchange is not out of a desire to suppress knowledge. It is to avoid my looking silly in a public forum. I think that there is still a lot of assembly and testing that would have to be done to assemble our own slices, and I am sure that I will make many mistakes along the way. (My 3 rd grade spelling skills will probably be evident from the attached file.) There are also limites to message length, which can be a problem for long winded people like me...

Additionally, I hope you realize that now that this data has been released the Tivo will likely be forced to change or encrypt future releases. Since I am not one of those subscribing to guide data, this will not effect me. However since the consenses those who do subscribe, and who are viewing this forum, is that the data should be posted immediately here it is. (Decisions are made by those who show up..)

I hope this is of some help to others investigating the issue. I look forward to any feedback.

[aram1s]

stryder:
Great pickup! Those files are going to give me something to digest for a while. They are still missing one key though. They do not mention what the "key" byte is for each of the things. This should make it a bit easier to figure out though.

thedoctor:
don't worry about looking silly. There are very few people who even have the ability to make significant contributions in a setting such as this. Looking silly is the last thing you need to worry about when working on a project like this. The silliest suggestion could be enough to spark a thought process in someone else that eventually leads to a missing piece of the puzzle.

I am going to say one thing up front though - once this starts getting near to actually working, I personally am not going to post any scripts or programs on the forum. Anyone who has contributed in any way I will send them to and they can do with them as they wish, but I am not going to release the results of a lot of this work out to the public for people to begin pirating tivo. I am doing this because of privacy concerns, not to beat tivo out of a buck (my tivos all have lifetime on them anyway). Also, it will be good to have this all worked out incase something happens to the company.

A

[TheDoctor]

I hate to waste space but I think we are withing 60 to 80 hours of coding from being able to produce a prototype slice file. Before we continue I would like to pose some problems and possible solutions and get some feedback before contiuing work.

Problem 1. There is problem with trying to ‘grab’ guide data off of the web. The scripts I have seen discussed so far appears to cause hundreds or even thousands of hits per user to obtain a single days worth of data. They could easily be detected and blocked by the service provider in a manner that would be transparent to a human user, but would include random bogus data to foil scripts. It would take minutes for them to produce these changes, and hours if not days to work around them.

Solution 1. Find a friendly provider. In exchange for providing the right of free use of a single week of their guide data they would receive free prime time plugs. (Prime time shows, which contain no advisory info, would get a special notice “Free data from www.PROVIDER.com” or “Go to www.PROVIDER.com for a preview of next week’s lineup...”. It would increase the slice file by two bytes per prime time show. (Yes, we would be bringing spam to Tivo, but it would be a legitimate under the circumstances. I don’t really support turning this into a commercial venture, but think that some compensation of services provided is fair.)

[TheDoctor]

Problem 2. The processing of guide data from html to load a 3 day slice file is probable going to be on the order of 1 to 3 hours. Those estimate come from working with the data on an 800mhz machine. Granted the processing times are rough guides from beta code, but it seems clear to me that this processing is more then can be done as a background task on the Tivo.

Solution 2. Find a host who is willing to process and provide a server for guide data. They could be provided the same ‘Prime Time Plug’. The data would be provided free to registered users of the site.
They would likely also have to be ready to fight legal action from Tivo. But so long as the guide provider has given permission to use their data, Tivo should have no legal ground for complaint.

[TheDoctor]

Problem 3. Tivo will likely respond by making new unites unhackable and by downloading prom updates to existing subscribers to prevent them moving to a new guide at a later time. This can EASILY be done! A change requiring an encrypted checksum for guide data could be added and under current laws would be illegal to circumvent.

Solution 3. Don’t really have one. Tivo designed great hardware, and I wish they had focused on getting their revenue from that instead of guide data. If Tivo had chosen to provide the box as an home multimedia solution, with a number of available upgrades… They have a number of business considerations as well, and shareholders who wanted immediate profits instead of a long-term market buildup. Additionally MPAA and others would like to see the digital recording movement fail. (They have already been successful forcing the HDTV broadcasts standard include the ability to block recording.) Free guide data is a direct threat to Tivo and I understand why they would fight it.

[TheDoctor]

Problem 4. Given that we have no solution to problem 3, further work on producing a source of ‘free’ slice files will see a lot of resentment from legitimate subscribers who have been fighting to prevent Tivo from ‘locking-up’ the platform. And we will very likely hand the future market to Microsoft UltimateTV.

Solution 4. Have none. Unless you can guarantee them an alternate source we are just pissing in the well.

To date, none of the code that I have written has been done using open source tools. If you are writing scripts using those tools please read the license, you may find that you are obligated to release the tools you develop. It is not legally stealing from Tivo to implement an alternate guide any more than it is to use ‘gcc’ instead of ‘MS VC++’. It is legally stealing to violate the GNU public, or other open source licenses.

I am taking a few weeks off from this. I’ll check back to see if anyone can come up with solution for these problems.

[sir_lunatic]

The answers to your problem?!?

1. There is "NO" problem with trying to ‘grab’ guide data off of the web. The script we are using as a base has existed for quite some time and has quite a large user base to begin with. There are even commercial products that use this script and variations on the theme. This is why we chose to use it.

2.We have said from the begining that the processing will require a seperate machine to cook data and that the Tivo doesnt have the processor to complete such a task.

As for giving away guide data for free, it will never happen. The guide data business is a very well protected industry. I know this because I work in this industry.

3. If Tivo makes changes that make the box unhackable, so be it. I have a backup of my current tivo and can prevent it from going to tivo to get an update. I currently dont allow it to go get data from Tivo now.

4. If you truly believe your statement in 4, dump all the stock you own and buy Microsoft. If just a few of us can redirect such a big market with such a miniscule hack, well then Tivo deserves to die. But I truthfully don'y buy it. I really dont think they give a damn. The data we get from TvGuides site will not be as complete as if we were to get their raw data. Most people that they market this thing too dont have the know how to do what we are doing. Dont beleive me, look at some of the questions asked in some of the threads over at AVSForum as well as a few unanswered ones here.

Just my thoughts.........

[Fugg]

"Problem 4. Given that we have no solution to problem 3, further work on producing a source of ‘free’ slice files will see a lot of resentment from legitimate subscribers who have been fighting to prevent Tivo from ‘locking-up’ the platform."

tivo has been working on "locking up" the mfs region since Tridge asked for their aproval to release his extraction software. to think otherwise is just silly.
i'm afraid the fruits of their labour are folded into version 2.5.

[sir_lunatic]

Oh yes, dont get me wrong. I fully believe they will lock the thing down. But it sure as hell wont be because of us. As you said fugg, they have been discussing that for sometime now. Its only a matter of when. 2.5? Who knows. They may make an attempt at it. But remember boys and girls, if they can get data on it, so can we.

[aram1s]

Some responses, not in any order.

While the open source thing is something to worry about, nothing that I have written so far is based on anything else. I have literally written all of my stuff from scratch. If you have used any of the open-source scripts you might want to consider rewriting your code to call the external scripts' subroutines instead of writing your code into them That does not violate the GPL.

With regard to tivo updating their systems, I would not worry about it. As long as we continue to work with the current operating systems (I am working with 1.3) the encryption stuff will not apply.

Also, I think that 60 to 80 hours is the point where we might have a rudimentary script running without every last bit of info that we want, but enough to get basic data into the bo.

A

[jasch]

First off, I have to congratulate everyone, because I believe the current efforts ar really worthwhile. In my case, TIVO offers no lineup for my current location (out of the US), but I could construct my own lineup using TVGuide information from their website (some channels from X lineup, others from Y lineup). They even have a lineup for my country's cable operator...

Anyway, if at some point our efforts could generate an ASCII slice to be imported into the TIVO, it would be fairly easy for me to generate a 'spider' or something similar that would go to TVGuide's site, download a couple of days of my 'custom' lineup, and output all that to a ASCII file I could later import in my Tivo.

Again, congratulations to everyone, I believe this thred goes in the right direction, and if somebody needs any help from me, or you guys still want to move this to a private -exchange- of emails, I could provide a private mailing list for us to use.

Thank you

Jorge Asch
San Jose, Costa Rica

[Fugg]

may be a dumb question but,

are you guys using tridge's homemade slices files as a reference?

[mwsmith824]

Yes, I've been using Tridge's files to work on picking it all apart. They were easier than copying them off my box.

[Fugg]

Well, I'm starting to see posts from folks who are in the 2.5 beta stating that the new version seems to be locking up the system pretty tight. No more bash prompt access in version 2.5.

The only way I can see to be able to keep the functionality I presently have w/2.01 is to prevent my standalone tivo from calling home.

Thanks to the minds in this forum, I am able to bypass most of the nags but I'm still faced with the problem of the guide data.

I understand the concern of those working on this and I don't want to be perceived as trying to develop a sub hack and attempting to bring about the downfall of tivo. Far from it. The tivo I have in the living room (origional unit, 2 years old) has no extra hacks and I will gladly continue to sub and welcome any updates. I purchased my second unit to "play" with and that has become the best investment I've made in a long time. The things I am able to do with it are nothing short of amazing. The thought of giving up those extras w/2.5... well, it's just not something I want to do. As far as that goes, I'm not opposed to continuing to pay the monthly sub to tivo on my second unit, as well as the first, even tho the second unit won't be calling home anymore. I'm not out to get something for nothing, i just want to keep what I now have.

Since the technical disscussion in this thread seems to either have stopped or been moved to some private venue, I respectfully ask that those who are working on this please continue to do so publicly. The rate at which i can learn to help myself is VASTLY increased when I can follow along with the disscussion of those who are more advanced than I.

Please?
:)

Fugg

[stryder]

As far as I know this discussion is still public, unless I was left out of it as well :).

I think people are caught up in "real life" at the moment.

[Vadim]

Hi all,

Sorry to be no help, but I'm working on DTivo, trying to get bash promt back. The thing that slows me down is lack of spare hard drives to restore backups on. Guys don't beleive anyone that says TiVo will lock up the box. They don't have the power to do that. The boxes are slow and there is no way they can run real time encryption. No need to panic, it will be fixed.
The problem is TiVo restores the backup files, digital signature in crupto is the problem, and that can be fixed, just like the serial number. Don't worry about 2.5, I only look forward to it.
I'm on DTiVo so those dual tuners are very interesting. I'm adding the 2nd cable for the tuner now. :)

[stryder]

Well It sounds like I may be needing to buy a DTivo box so I can play with 2.5 and the dual tuner support. Any tips on where to pick one up cheap?

[Vadim]

Got mine for 130 shipped. It was some broken one on ebay.
Actually it has no accessories, no remote, nothing
The back where you have the connectors to the tuners, one of them was beaten out. So I went to Trash Shack and got one that looked simular. I replaced it and it works fine. Doesn't look like the orignal one but who cares right? Then it had some dents on the case but I didn't care.

Then I took one of my SA tivos that broke. Send it it for repair (under warranty), i send it in without accessories. Got it back with all new accessories :)

So now I have this nice DTiVo for 1/3 of the price. No subscription or anything requried :)

You could try ebay and search for them, so far I haven't seen any but maybe you'll find some..



Originally posted by stryder
Well It sounds like I may be needing to buy a DTivo box so I can play with 2.5 and the dual tuner support. Any tips on where to pick one up cheap?

[trainboy]

In response to TheDoctor's Problem 1, I believe that one should be a good citizen even if the content provider won't find you and kick you off their site. Thus, one should try not to download too much data from the quide provider's site no matter whether they care or not.

In another thread, http://dealdatabase.com/forum/showthread.php?threadid=1581, I mentioned how I was thinking of not overloading the TV Guide site while pulling guide data. Using the method described, guide data could be pulled via a few hundred (at most) hits spread over a 24 hour period. This would be noise level at worst.

[TheDoctor]

On a technical note.
After using dbload on a slice file, you should also invoke the Gc and Index routines from TClient. Gc will remove outdated guide data. Index will enable search by names etc.

This is done by passing correct info to
::EVT_DBGC_REQUEST

info being
GC_ONLY_NOW 0
INDEX_ONLY_NOW 1
GC_AND_INDEX_SOON 2

I have verified that it will work by involking 0 and 1, but have not scripted it yet. (I like things now, not soon...)

Some varient of this would likely have to be done with any script based approach as well.

No, I am not generating slices yet, have been on vacation.

[TheDoctor]

Still working on it... about 24 hours after loading I got a new nag screen, even when all service states appear correct.... checking...

[SuperVHS]

jpag's site has various utilities for adding program guide:

http://www.geocities.com/paglierani/

The readme within the update.zip file refers to his clean.tcl file that may do the cleanup that you refer to.

Enjoy.........

[TiVo_Canada]

Sorry if this has been asked/answered before, but if I want to try and load one of Tridge's slice's how do I do that?

I realize it is 'dbload' but what argument do I use for DB?

Thanks.

[hwboy]

set db [dbopen]
dbload $db <file>
dbclose $db

[TiVo_Canada]

Thanks!

The dbload works like a charm.

However, not able to get the data actually in a useful state.

ie:

::EVT_DBGC_REQUEST

info being
GC_ONLY_NOW 0
INDEX_ONLY_NOW 1
GC_AND_INDEX_SOON 2

all fails. Maybe I'm not running it correctly. I used:


event send $TmkEvent::EVT_DBGC_REQUEST $TmkDataChanged:GC_ONLY_NOW 0

which gives me errors.

All the data that I loaded seems to be WAITING in /Database

Still in BoatAnchorMode and it claims I have NO data

Suggestions?

[TiVo_Canada]

I ran "TClient" which failed on dialing out, however I notice that /var/tmp/TClient.res now has values:

TClient::login:retcode 1
TClient::backHaulDone

I changed it to:

TClient::login:retcode 0
TClient::backHaulDone

and rebooted and now I'm completely locked out of my TivoNet!!

Shot myself in the foot.

DON'T DO THIS!!!

I had to haul out my serial cable and connect, edit the file and reboot to get my TivoNet to work again.