6.3x on a Standard (Non-HR10-250), S2 DTivo

[tivo4mevo]

It's long been known that software versions have varying degrees of compatibility between different lines of tivos.

Most noteably, SA version 4.x was made to run on DTivo units (both uma4 and uma6, thanks to everyone here at DDB). It was reported that DTivo software version 2.5.2 could be made to run upon S1 SA units, and DTivo version 3.1.5x (specific to the HiDef HR10-250 DTivo) ran fine on non-HiDef DTivos, though there were few compelling reasons (aside from slightly better, stock driver support) to do so.

It turns out, that as Jamie has mentioned (http://dealdatabase.com/forum/showthread.php?p=278102#post278102), one can easily run 6.3x on a standard DTivo.

Why would one want to do this?
6.3x, once properly hacked, provides two notable benefits over 6.2x, HME and 802.11g driver support (including the Tivo-branded adapter); on the other hand, 6.3 lacks MRV, as that code was stripped out. But with HME allowing easy UI control, applications like MovieLoader (http://dealdatabase.com/forum/showthread.php?t=51987) open the door to MFS_FTP-based show transfers initiated via remote from the comfort of one's couch. HME also allows podcasts and other uses for dtivos.

Having once been a poor wireless fellow, the enhanced driver support of 6.3x was of interest to me and may be of interest to others as well.


When attempting to install 6.3x on your unit, there are two main paths: installing from an image or upgrading via slices.

1. Installing from an image:
-------------------------------------
When installing from an image, three problems occur. First, most available 6.3 images were created from a 250GB drive (Instantcake included?). So one cannot easily restore such an image to a smaller drive. I don't know of any way to shrink MFS partitions other than rebuilding MFS from scratch.

Second, even if you do have a 250GB+ drive, you must be careful when restoring to ensure a proper partition layout.

An image of a stock tivo drive will include two MFS partition pairs, each roughly half the total size of the drive, with the root, kernel, swap, and var partitions sandwiched between. With a stock tivo 250GB drive, the Second MFS media region starts at LBA 64 and has a suspicious size of 128.1G. Thus all non-MFS partitions (kernel included) lie beyond the reach of your S2 DTivo's PROM, which cannot address beyond 137GB (128GiB). One should not confuse the PROM with the kernel that the PROM is loading. While the kernel might be lba48-aware, the PROM code on a standard DTivo is not.

When restoring you'll want to avoid using the "p" option of MFSTools restore, as I believe that attempts to mimic the default partition layout. A quick pdisk -l should confirm the correctness of your restored image's partition map.

Third, while not fatal, MFSTools 2.0 restore has the alternate root/kernel and swap > 127MB initialization bugs. Spike2K5's version of MFSTools included on his mfslive boot disk (www.mfslive.org) fixes those problems (Beta versions of mfslive's restore include a "-P" option, intended to ensure that kernel partitions are placed below the 128GiB mark, which might further address the second point above).

Two remaining annoyances with the image method are that 6.3 images tend to be rather bulky and that you will lose your recordings upon reimage. For those reasons, some might prefer upgrading via slices.


2. Upgrading via Slices:
-------------------------------------
Once you have gotten a valid set of 6.3 slices, if you simply try to dbload them into MFS, you'll find that the new version of software does not appear when you "echo 'mls /SwSystem' | tivosh". This is because the slices will have an unsatisfied loopset dependency, and there are three ways to solve this problem.


Obtain a valid HR10-250 loopset slice: I've not seen any public versions of this slice recently.
Extract the needed loopset resources from a running HR10-250 and load them into your target tivo before dbloading the slices: tools to do that can be found here (http://dealdatabase.com/forum/showthread.php?t=29775), but note that you'll likely encounter problems with both the size and the reinsertion of the extracted resources.
Fake the needed loopset resources before dbloading the slices: the loopsets on the HR10-250 differ from regular DTivo loopsets in that HR10-250s have both a 4x3 and 16x9 version of the standard DTV loopsets. Given the purpose of this thread, 16x9 ratio loopsets won't be needed, so it should be safe to create fake versions of all needed 6.3 loopsets such that they point to our existing S2 (4x3) DTV loopsets (I'm not even sure that the 16x9 loopsets differ from the 4x3 ones, other than the aspect ratio).
The third option is the clear choice here. No reason not to reuse what we already have, and no reason to unnecessarily push bits around the Internet. Dubbya had kindly posted a link to his work (http://www.pvrhax0r.com/forum/showthread.php?s=&threadid=18) that he did to solve the loopset dependency issue while upgrading a DTivo from 3.1.x to 4.x, so his script is a good place to start.

It's necessary to figure out the mapping between the different loopsets, but that's trivial, and I include it here.# 6.2x to 6.3x mapping
clone_loopset 6506965 14610911
clone_loopset 6506965 16000484
clone_loopset 6055486 14610925
clone_loopset 6055486 16000566
clone_loopset 6055491 14610961
clone_loopset 6055491 16000680
clone_loopset 6055505 14611080
clone_loopset 6055505 16001087
clone_loopset 6506970 14610997
clone_loopset 6506970 16000794
clone_loopset 6055496 14611032
clone_loopset 6055496 16000894
clone_loopset 6055501 14611058
clone_loopset 6055501 16001023
In addition, it seems that Dubbya's script seeks to only fake the loopsets in order to satisfy slice dependencies and allow the upgrade to take place. We'll want to go a step further so that 6.3 will correctly display our existing loopsets. While it's a bit ad hoc, we can replace the script's loopset naming with the following to accomplish this: set name [string trim $name 1]
if { $to > 15000000 } {
set name "${name}FS_16x9_1"
} else {
set name "${name}FS_1"
}
puts "Creating fake LoopSet Resource $name\n"
Executing that script on a standard DTivo before you attempt to dbload the 6.3 slices should resolve the loopset dependencies, and allow you to upgrade it to 6.3. If you dbload the 6.3x slices before faking your loopsets, you'll encounter the problems described later in this thread. With the 6.3x software now fully present in MFS, the upgrade and hacking process will be standard and all of the existing information for 6.3 will be valid for your unit. On my unit, the lack of a SerialNumber environment variable caused installSw.itcl to barf; running export SerialNumber=`/tvbin/crypto -gsn` and then executing installSw.itcl again was enough to successfully upgrade.


Once you've successfully upgraded or reimaged your unit and then and hacked it, you'll find that fooling around with the OTA related UI menus will cause a reboot. Beyond that, everything else should work.

[tvtyme]

Be sure to use the backticks (as opposed to the single-quotes) in command:

export SerialNumber=`crypto -gsn`

Verify by typing "echo $SerialNumber" and it should return your TSN (Tivo Service Number)

L8r

[tvtyme]

tivo4mevo, if I understand you correctly:

Fake the needed loopset resources: the loopsets on the HR10-250 differ from regular DTivo loopsets in that HR10-250s have both a 4x3 and 16x9 version of the standard DTV loopsets. Given the purpose of this thread, 16x9 ratio loopsets won't be needed, so it should be safe to create fake versions of all needed 6.3 loopsets such that they point to our existing S2 (4x3) DTV loopsets (I'm not even sure that the 16x9 loopsets differ from the 4x3 ones, other than the aspect ratio).

Since I can't find a valid HR10-250 loopset slice, can I load the loopset slice file for my SDtivo model after I fake the needed loopset resources?

I slice-upgraded from 6.2 to 6.3a without the loopset slice but, of course, I was missing the background animations.

L8r

[tivo4mevo]

If your starting 6.2 image correctly displayed its loopsets, then your slice upgraded 6.3x should as well.

If you lost the loopset tystreams at some point (i.e., the fsid's specified by the Resource/VideoClip objects weren't properly backed up), then yes, reloading the standard DTV loopset slice should restore them.

Remember to set the server version of the existing ones to 0 to ensure that they are actually overwritten when you dbload the slice.

[SpoonsJTD]

Is anyone doing this? I'm an IT'ish person in the real world, and it'd give me a warm fuzzy to have all my systems on the same software. MovieLoader's a good MRV replacement, and having HME on all my boxes might actually get me off my but to write some things.

Any experiences to report?

[tvtyme]

If your starting 6.2 image correctly displayed its loopsets, then your slice upgraded 6.3x should as well.

If you lost the loopset tystreams at some point (i.e., the fsid's specified by the Resource/VideoClip objects weren't properly backed up), then yes, reloading the standard DTV loopset slice should restore them.

Remember to set the server version of the existing ones to 0 to ensure that they are actually overwritten when you dbload the slice.

Ok, after my initial 6.2 fresh install (and confirmation the backgrounds worked) I slice-upgraded to 6.3a. No backgounds. So I tried this to get the backgrounds back:
1. Ran dubbya's expire_loopsets.tcl found here (http://www.pvrhax0r.com/forum/showthread.php?s=&threadid=18).
Tivomemo, is that what you meant by "setting the server version to 0"?
2. dbloaded the 6.2 DTV loopset (loopset-dtv-Series2.slice)
3. Rebooted
Still no luck
Shamefully, I'm stuck :confused:

[tivo4mevo]

1. Ran dubbya's expire_loopsets.tcl found here (http://www.pvrhax0r.com/forum/showthread.php?s=&threadid=18).
Tivomemo, is that what you meant by "setting the server version to 0"?Yes.

As for why your backgrounds aren't displaying correctly after the upgrade, you may want to ensure that the loopsets are named correctly.

After faking your loopsets, you should see each /Resource/LoopSet in triplicate. Something along the lines of this:DirecTV_Blue_1
DirecTV_Blue_FS_1
DirecTV_Blue_FS_16x9_1

Incorrectly named loopsets with correct ServerIDs will still allow the 6.3 slice upgrade to proceed, but the resulting 6.3 system won't be able to find the loopsets (and errors should appear in the logs saying as much).

[SpoonsJTD]

I have 6.3d in MFS on my HR10-250, and I've got slices for 6.3b that include SwSystem. Can I add the 6.3b swsystem slice to my 6.3d extracted slices and use that to 'crossgrade' my s2's? Or should I just use the 6.3b slices to crossgrade and then apply the file differences to get it from 6.3b to 6.3d?

Also, has anyone taken a look at using any of the resource tools out there to hide, remove, or otherwise disable the OTA-related menu items (to make it more spouse-friendly)?

[tivo4mevo]

I don't believe you can mix and match slices from different versions (I haven't explicitly checked that for 6.3x); Such an attempt might end up with neither version reported as present in MFS, as both are missing parts.

That said, you've little to lose by trying. Load all your 6.3d slices, sprinkle in swsytem from 6.3b, and check MFS. If nothing shows, then simply load the remainder 6.3b slices and upgrade.

I haven't looked at culling the OTA menus but agree that modifying the brf files (or possibly tivoapp) would be a good place to start.

[SpoonsJTD]

I dbload'ed the 6.2b slices before I tried to run the loopset script. I am getting the 'commit failed' error. I found a post (of course, now I can't find it again) where alphawolf or someone described a problem that could occur if you loaded the swsystem slice before resolving the loopsets. Not sure if that was my problem, but I restarted from a fresh image to try again.

I am going to do the straight 'fake loopset'. tivo4mevo, could you describe which part of his script you replace\augment to add the naming? I don't know tcl and had a hard time figuring out where to put the new naming code. I think I got it right, but like i said, I was getting 'commit failed', even running the base script with the clone list replaced.

[tivo4mevo]

I can only show you the door, you're the one that has to walk through it.

Seriously though, sounds like you're almost there, and experimentation is the best way to learn.

Try running your modified fake_loopset script and then checking to ensure that what appears in MFS under /Resource/LoopSet matches what I describe. If you find your faked loopsets are misnamed, the erroneous naming should help you zero in on how to correct your script.

[SpoonsJTD]

I restarted from scratch and ran the fake_loopset script first before dbload'ing the slices and all was well. Removed the reboot from installSw.itcl, and successfully installed 6.3b on my DSR7000. I ran out of time last night, but I'll either copy over my startup scripts and hacks from my HR10-250, or I might look into AlphaWolf's init framework.

This is a 'dev' machine for me, unsubbed with a card, just so I can zero in on the process and config I want before I apply it to my live boxes.

Thanks for the initial post, tivo4mevo. I might revisit the script edit to do the renaming once I'm done with the config. Since it is a dev box, i'm not real concerned with showing the loopsets properly just yet as long as I can figure it out before I apply everything to my live systems.

[SpoonsJTD]

I also forgot to mention that after reboot and 6.3b is 'live', I plan on applying the 6.3d files extracted from the slices from my HR10-250. I assume this is ok? No DB changes from 6.3b to 6.3d?

[SpoonsJTD]

Mounted the new partition, rehacked, and let it reboot. Got the 'system update' message, and sweet sassy molassy - 6.3b running on my DSR7000, without loopsets of course. Need to patch tivoapp, decide on whether to try Alphawolf's init framework, and fix my loopsets, and I'll be ready to apply it live. I think I might 722 my dev box and replace one of my live boxes. Got a few DSR 7000's from a Weaknees closeout a while back and would like to get all my hardware consistent. I'll eventually have 2 sub'd DSR7000's, and HR10-250, and an unsub'd DSR7000 to use as a dev box, ALL RUNNING 6.3!

Thanks tivo4mevo.

[SpoonsJTD]

Just an update -- I did have the loopset naming replacement correct in the script, apparently the loopset faking script needs to be run before dbload'ing the SwSystem slice. On my second 6.3x-on-S2, I got the loopsets right to start with. Reran the loopset faking script (with loopset naming replaced) on the first 6.3x-on-S2 box, and it fixed them.

It's so nice having the same software on all my boxes now.

[SpoonsJTD]

Dubya hasn't posted here since 2004, and pvrhax0r has been inactive (excluding the spammers who still seem to find it) for a long time.

Someone can delete this post if they feel it's inappropriate, but I'm attaching the zip file mentioned in the OP so that you don't have to register at pvrhaxor to get it:

The attached file, with explanation, was originally found here (http://www.pvrhax0r.com/forum/showthread.php?s=&threadid=18).

[sethjvm]

Thanks!

I seem to have run the fake_sa_loopsets.tcl and upgraded to 6.3c correctly on one of the three machines. I have not had a chance to verify that I still have telnet and ftp or run the superpatch with updates to get HME but it appears okay.

My problem though is that I somehow managed to screw up the upgrade on a second maching by dbloading the slices before running the fake_sa_loopsets.tcl script so I get the commit failed error when I run the script. I figure I have two options but hope for a third.

1. I am currently on 6.2a on partition set 6/7 but I could flip the boot page back to 6.2 on 3/4 and redo the 6.3c from the older partition set. This would not be too painful I don't think.

2. I fear that I may have to pull the drive and load Alphawolf's minimal 6.2 to start over. I fear this may be my only recourse.

3. Perhaps someone can suggest a way to unload the 6.3c slices from my active setup so I can run the fake_sa_loopset.tcl and then dbload. I am trying to figure this out. I found this thread http://www.dealdatabase.com/forum/showthread.php?p=213745 and started around post 97 that deals with loopset issues. Maybe I'll try Plainbill's post: http://www.dealdatabase.com/forum/showpost.php?p=213981&postcount=122.

[SpoonsJTD]

Hey Tivo4mevo, could you update the OP to make it clearly understood that you should fake the loopsets before dbloading? I think it's kind of hinted at, but it should be made pretty prominent. I did the same thing, but luckily for me I was starting from a fresh image to begin with (PVRUpgrade 6.2 image disk) so it wasn't painful to start over.

Can anyone else comment on how to rectify? Is there a dbunload that can be applied using the slice ID's to remove them? I didn't spend a lot of time trying to figure it out because I had the image.

[tivo4mevo]

I clarified the post.

sethjvm, I don't think flipping your bootpage will help. There is only a single MFS database (into which you have loaded the slices). Flipping your boot page to boot into your alternate kernel/root partitions would still access that same MFS database.

Starting over would certainly be an option, but you might experiment more before resorting to that (what do you have to lose?).

Your searches turned up good information. One solution that might be worth trying would be to try rubbishing all the 6.3c objects and then forcing garbage collection. Based on what ADH stated, it might work if you ensure that there are no lingering references by rubbishing all objects. The trouble would be tracking down all those objects.

Beyond that, forcing an MFS rebuild (through a Clear and Delete Everything) is reported to clear other software versions other than the Active, though I'm not sure what this would net you over re-imaging. If you're at this stage, you might want to experiment with progressively more destructive attempts (i.e., start by forcing an MFS check, then try performing an MFS cleanup, etc.).

[f-reality]

Ok, I have what may be a stupid question. Would it be possible to upgrade a currently running SD DirecTiVo to 6.3x, then pop the drive in an actual HR10-250? What ill effects, if any, would there be? If it would work, would it act like any old HD DirecTiVo, i.e. would it have problems upgrading to future software versions? I have a ton of shows on my current TiVo and have been putting off switching to the HD TiVo for numerous reasons (some shows may not want to transfer over, have to have extra drives to hold the shows assuming I want to reuse them, etc.). Heck, even if I got new drives for the HD-TiVo, I'd rather just MRV all the shows over (which you can't do with 6.3).

[sethjvm]

I have up and reimaged back to 6.2 on two of the boxes. The third box is running 6.3c but the DTV loopsets are missing. I'm so frustrated, I just can't seem to get the fake loopsets script right. I realize that you showed me a door and I need to walk through it but I keep hitting the doorpost! Can you give me some more hints about where the naming script needs to be replaced? I see this in the .tcl file as the set name section but I need some help understanding what this does.


set name "${name}_SAcompat_$to"
dbobj $loopset2 set Name $name
if { $port != "" } {
dbobj $loopset2 set Port $port
}
dbobj $loopset2 set ServerId $to

edit: As you can probably guess I am not a programmer since I suspect that anyone with a brain would get this with little effort.

[tivo4mevo]

Would it be possible to upgrade a currently running SD DirecTiVo to 6.3x, then pop the drive in an actual HR10-250? What ill effects, if any, would there be? If it would work, would it act like any old HD DirecTiVo, i.e. would it have problems upgrading to future software versions?Sure, I wouldn't imagine any ill effects if you stick to 480i output only. Other output resolutions might cause problems if the faked 16x9 ratio loopsets cause the box to barf. I haven't tried this for myself.

If that did cause problems, you could follow bullet one or two under "2. Upgrading Via Slices" in my original post to replace the faked ones with good 16x9 loopsets.



sethjvm, what do you see under /Resource/LoopSet in MFS after running your fake loopsets script?

[sethjvm]

Before running the cloning script:

bash-2.02# mfs_ls /Resource/LoopSet
dir: fsid=1534 count=8
fsid type name
-----------------------------------
1527 tyDb DirecTV_Blue_1
1537 tyDb DirecTV_Blue_w_DTV_1
1542 tyDb DirecTV_Blue_w_DTV_TiVo_1
1547 tyDb DirecTV_FindByName_1
1550 tyDb DirecTV_Green_1
1555 tyDb DirecTV_Green_w_DTV_1
1560 tyDb DirecTV_Green_w_DTV_TiVo_1
1565 tyDb HNS_WatchTV_1

After running the modified cloning script:

bash-2.02# mfs_ls /Resource/LoopSet
dir: fsid=1534 count=22
fsid type name
-----------------------------------
1527 tyDb DirecTV_Blue_1
4055 tyDb DirecTV_Blue_FS_1
4056 tyDb DirecTV_Blue_FS_16x9_1
1537 tyDb DirecTV_Blue_w_DTV_1
4057 tyDb DirecTV_Blue_w_DTV_FS_1
4058 tyDb DirecTV_Blue_w_DTV_FS_16x9_1
1542 tyDb DirecTV_Blue_w_DTV_TiVo_1
4059 tyDb DirecTV_Blue_w_DTV_TiVo_FS_1
4060 tyDb DirecTV_Blue_w_DTV_TiVo_FS_16x9_1
1547 tyDb DirecTV_FindByName_1
4061 tyDb DirecTV_FindByName_FS_1
4062 tyDb DirecTV_FindByName_FS_16x9_1
1550 tyDb DirecTV_Green_1
4063 tyDb DirecTV_Green_FS_1
4064 tyDb DirecTV_Green_FS_16x9_1
1555 tyDb DirecTV_Green_w_DTV_1
4065 tyDb DirecTV_Green_w_DTV_FS_1
4066 tyDb DirecTV_Green_w_DTV_FS_16x9_1
1560 tyDb DirecTV_Green_w_DTV_TiVo_1
4067 tyDb DirecTV_Green_w_DTV_TiVo_FS_1
4068 tyDb DirecTV_Green_w_DTV_TiVo_FS_16x9_1
1565 tyDb HNS_WatchTV_1

This looks like it may be right.

Is it possible for the loolpset naming script to run to completion with some incorrectly applied code?

[sethjvm]

I got it now. Thanks!

[kfcrary]

Could someone point me toward an explanation of what's going on with the loopsets? I'm particularly curious why sometimes I need them (when I upgraded from 3.1.1 to 6.2) and sometimes not (when I upgraded from 6.2 to 6.2a). I had no trouble either time, but I didn't really understand what I was doing.

[PlainBill]

Could someone point me toward an explanation of what's going on with the loopsets? I'm particularly curious why sometimes I need them (when I upgraded from 3.1.1 to 6.2) and sometimes not (when I upgraded from 6.2 to 6.2a). I had no trouble either time, but I didn't really understand what I was doing.

Short, simple explanation: Loopsets are short recordings used as backgrounds for the various menus. If they are missing you get anything from a transparent background to a system that won't boot. They are stored in the mfs database. Loopsets are quite large compared to the software, so they are not included with the slices, and do not change with software upgrades.

You should never need loopsets with 'normal' software upgrades (3.1.1c to 3.1.1d; 3.1.1d to 3.1.1e; 3.1.1e to 6.2; etc). Each type of system (TiVo, SD DirecTiVo, HD DirecTiVo) has it's own loopsets. So while you could load 4.0.1 onto an DSR7000, later you could not simply load the 6.2 slices to upgrade to 6.2. It wouldn't even allow you to load the slices! Instead some nice person supplied a package that included the loopsets and the slices.

A similar problem exists with going from 6.2 to 6.3x. 6.3x requires high resolution loopsets that are not normally found on a 6.2 system. Because a SD system would never actually use them, it is possible to create dummy loopsets. These must be in mfs before loading the slices.

PlainBill

[sethjvm]

I really enjoy having the HME apps like Movie Loader and Galleon available on my unsubbed S2 DTivos so I wanted to post a thank you to Tivo4mevo, SpoonsJTD, and Dubya for making this process so easy.

[tsanga]

I have 6.3d in MFS on my HR10-250, and I've got slices for 6.3b that include SwSystem. Can I add the 6.3b swsystem slice to my 6.3d extracted slices and use that to 'crossgrade' my s2's?
Spoons,

Did you ever get this "crossgrade" to work? From reading the thread, sounds like you just went to 6.2b then replaced the tivoapp to get it to 6.3d.

[superleo]

A new software rollout just started ...

It looks like ALL DirectTiVos will be running on software 6.3e

[SpoonsJTD]

Spoons,

Did you ever get this "crossgrade" to work? From reading the thread, sounds like you just went to 6.2b then replaced the tivoapp to get it to 6.3d.

Nope, I did just that (except 6.3b to 6.3d). I'm in the process of installSw.itcl'ing them to 6.3e. This whole thing was a nice learning process.

Nice thing about getting them to 6.3d first is that it makes the jump to 6.3e as simple as copying some directories, my rc.sysinit.author, and the kernel over to the other partition pair.

[Rorschach]

Is the upgrade being sent over satellite or is it going to require a call in?

[cgaliher]

It's happening over the satellite, but seems a tad unpredictable. I've gotten two 6.3e slices so far, but neither for my service code.

[jt1134]

It's happening over the satellite, but seems a tad unpredictable. I've gotten two 6.3e slices so far, but neither for my service code.

I just noticed that also.

[crashHD]

same here, too. I got 2, for service codes 121 and 151, on a dvr 40 with a code of 321. Sequential order, maybe?

Has anyone gotten a 6.3e slice on an R10? Does anyone even know if the R10's are going to be included in this update?

[jt1134]

Does anyone even know if the R10's are going to be included in this update?

I believe its included also.

[w2kr]

same here, too. I got 2, for service codes 121 and 151, on a dvr 40 with a code of 321. Sequential order, maybe?Perhaps not. I got service codes 151 and 381 on a TiVo that requires 351. I also got service codes 101 and 121 on a TiVo that requires 321.

[crashHD]

I mixed up one of the numbers before.

I meant to say 101, and 121, on the 321 unit, but it does kind of seem more random than anything.

[cgaliher]

It now appears it is neither as unpredictable nor as random as I originally thought. After banging my head against a wall for awhile, modifying my group memberships, and generally getting frustrated that I only got two 6.3e slices, I did the ultimate test. I pulled out my original unhacked image and restored it to a spare drive. And forced the unit to call home.

My 301 unit immediately downloaded and installed 6.3e-1-2-101 (NOT 301!)

So, I put in my hacked drive, did a manual upgrade using the 101 slice, and the unit seems to be working great now. It appears DTV (or Tivo) decided to consolidate some of their codebase with 6.3e so multiple service codes are served with the same slices now.

[w2kr]

Well if the consolidation of images is indeed true, we should be able to create a mapping from the old service code to the new. I have 4 DTiVos, each of which have only 2 6.3e images in MFS/SwSystem.

Unit 1, service code 351 (Hughes DVR40), 6.3e codes present, 151, 381
Unit 2, service code 351 (Hughes DVR40), 6.3e codes present, 151, 381
Unit 3, service code 321 (RCA DVR40), 6.3e codes present, 101, 121
Unit 4, service code 301 (Philips DSR704), 6.3e codes present, 101, 121

[crashHD]

I will add mine, to help with a mapping:

Unit 1, service code 321 (RCA DVR40), 6.3e codes present, 101, 121
Unit 2, service code 521 (DirecTV R10), 6.3e codes present, 521.

Since the R10 is the oddball in this mix (only Series 2 DTivo that's not hardware-compatible with the rest), do you think that means it's 6.3e slice (-521) is different from the rest? I.e. mismatched service codes in the past never prevented a Dtivo from running, but is that still the case now with the R10, since it is not exactly the same hardware?

[Thinkdiff]

It now appears it is neither as unpredictable nor as random as I originally thought. After banging my head against a wall for awhile, modifying my group memberships, and generally getting frustrated that I only got two 6.3e slices, I did the ultimate test. I pulled out my original unhacked image and restored it to a spare drive. And forced the unit to call home.

My 301 unit immediately downloaded and installed 6.3e-1-2-101 (NOT 301!)

So, I put in my hacked drive, did a manual upgrade using the 101 slice, and the unit seems to be working great now. It appears DTV (or Tivo) decided to consolidate some of their codebase with 6.3e so multiple service codes are served with the same slices now.

The reason it works fine is because the service code doesn't really do anything. A 151 TiVo will boot any of the other ones and vice versa. It just displays the wrong info in the About TiVo page. This is how you can take an image from any Series2 and put it on any other Series2 (inside the same group, ie: DTiVo to DTiVo).

The ultimate test would be to turn off the "upgradesoftware=false" option and see what upgrade the TiVo automatically upgrades to. I assume running installSw.itcl with no version number will also simulate the same thing and pick the proper software for the TiVo.

[Narf54321]

This is how you can take an image from any Series2 and put it on any other Series2 (inside the same group, ie: DTiVo to DTiVo).

I know what you meant, but I feel the need to clarify for anyone else coming across this thread. Just be wary of making broad statements, because not all Series-2 machines are equal especially the standalone units. For example, the gryphon software updates won't work on an ibis/gen04 machine even though they are both called "S2". In other words, the -140 and -540 software are incompatible (usually at the kernel level), so watch out. This often shows up as the root of a number of n00bie problems/confusion here on the forums when attempting to update their hardrives or hack their unit with an InstantCake CD or other 3rd-party image. I believe there are also software issues between the Series-3 and TivoHD units, where you wouldn't expect there to be any.

[HiDefHusker]

Unit 1, service code 351 (Hughes DVR40), 6.3e codes present, 151, 381
Has anyone installed 6.3e on a Hughes SD-DVR40? If so, any idea which one of these slices was installed?

[wcr]

same here, too. I got 2, for service codes 121 and 151, on a dvr 40 with a code of 321. Sequential order, maybe?

Has anyone gotten a 6.3e slice on an R10? Does anyone even know if the R10's are going to be included in this update?

My unmodified updated last night to 6.3e.

[imaloserbaby]

Unit 3, service code 321 (RCA DVR40), 6.3e codes present, 101, 121


Oops, mine is a 301 (Philips DSR704), 6.3e 101,121 present. I just successfully, manually, slice upgraded using the 6.3e-01-2-101 slice.

HiDefHusker: Based on the results so far, I'd say it's highly likely that 101 is wanted for you, as I understand it, the DSR704, DSR708, RCA DVR40, and Hughes DVR40 are all internally the same (x8xx model have 80gb drive rather than 40gb but other than that). All "RID" versions of an S2 DTivo.

[blueman2]

My HDVR2 has the following now:

Directory listing of /SwSystem
Name Type Id Date Time Size
6.2a-01-2-151 tyDb 4092779 03/10/07 15:55 724
6.2a-01-2-301 tyDb 4092780 02/17/07 03:29 700
6.2a-01-2-321 tyDb 4092781 02/17/07 03:29 700
6.3e-01-2-101 tyDb 4852301 08/07/07 02:55 780
6.3e-01-2-121 tyDb 4852306 08/07/07 02:55 780
6.3e-01-2-151 tyDb 4852307 08/07/07 02:55 780
6.3e-01-2-381 tyDb 4852308 08/07/07 02:55 780
ACTIVE tyDb 4092779 03/10/07 15:55 724


So, what does 6.3e add? Has anyone done the upgrade on a hacked system yet?

[crashHD]

Does anyone know if this works the other way around? I.e. will an HR10 run software from a standard def. DTivo, like 6.2a? No reason, just curious. I would imagine if it does run, HD and OTA would not likely be functional. Since the HR10 will soon only do SD from the sat anyway, seems like it could potentially provide for stable SD operation if one was willing to give up OTA, no?

[jt1134]

Does anyone know if this works the other way around? I.e. will an HR10 run software from a standard def. DTivo, like 6.2a?
Sometimes it does, sometimes it doesn't. 6.2 was toyed with (http://www.dealdatabase.com/forum/showthread.php?t=42573) on an HR10 but never had any documented success.