Which version of Tivoapp is used in the last image and is there a de-compiled version available?
Printable View
Which version of Tivoapp is used in the last image and is there a de-compiled version available?
It's version 3.0, and there is no decompiled code available. This would be very difficult to do and be highly illegal. Attempts to decompile the code would be dangerous as TiVo Inc would likely pounce on all tivo communities.Quote:
Originally Posted by sikkie
It is fairly easy to disassemble the code (from machine code into assembler) which has allowed people to extend the live buffer (aka bufferhack), etc. While technically illegal this is more about patching the existing binary rather than attempting to alter and "recompile" it.
Having the source code available would be very handy for those of us wishing to patch or extend the existing application - but it's also very dangerous for TiVo Inc as other commercial companies and communities can steal the code and compete in the same market as TiVo Inc (currently US, UK and Canada).
Thanks.
I agree that technically speaking, there is not a huge difference between decompiled and commented disassembled. Is the commented disassembled code available to play around with? It is certainly not worth it to re-design the wheel for every one.
I don't know of any commented disassemblies... in fact the v3.0 binary had all it's symbols stripped so it's very much a hit and miss thing. For instance to increase the buffer from 30 minutes really just involved looking for all the values that matched 30 minutes and changing them one by one in a trial-and-error process.Quote:
Originally Posted by sikkie
If you let me know what it is you are trying to alter then I should be able to give you a pretty good idea on just how hard it will be.
Always best to speak to the specialists!
Like many other TiVo fans I am trying to prevent the buffer from resetting/clearing during channel changes. To search for this, is probably not as easy as looking for the 30 min buffer, but all the buffer commands should be close to each other?
Thanks.
Yes... this would be a very handy modification (especially if you accidently change channel while catching up on live TV!). I can't think of anything that would be upset by such a modification. The modiciation itself could be as simple as removing the call to the "reset buffer" call... but finding this would not be easy. I'll have a dig around and see if I can find any promissing sections of code.Quote:
Originally Posted by sikkie
Great! at least somebody understanding my thinking and the benefits. I also thought it could not be too difficult.
Please say if I can help disassemble or do something. I am eagerly awaiting your reply.
Any luck on this?
Nope. There are no symbols in the tivoapp binary so it's a pretty large job... and by "a pretty large job" I mean wading through one and a half million lines of assembler trying to figure out which part is resetting the buffer pointer.Quote:
Originally Posted by sikkie
Far from a solution, but a push in the general direction, if you hex edit tivoapp at address 0x46AB38 and change it
from 41 86 00 34 to 48 00 03 F4
then it *sort* of does what you want.
The live cache doesnt get deleted, but the progress bar still thinks it has been (probably along with other parts of the system) - the first visible result is that when you change channel the 1/2 hour buffer is basically squeezed into a progress bar which is a couple of pixels wide. This means if you rewind or fast forward you either end up back half an hour or watching live tv, with very little control in between. It also seems to get angry sometimes and not let you ff/rwd past a certain point, or thinks you are at the start of the progress bar when you are actually at the end. It's possible that it also may not be deleting the cache that is older than 1/2 hour. Chances are it broke other stuff too...
So to summarise:
1) Live TV cache is not deleted when you change channel
2) Lots of stuff went screwey/got broken by skipping a large chunk of code
3) An entry point is given in the file (address 0x46AB38) to further narrow down exactly which part of the code resets the cache (instead of just skipping the entire chunk).
4) Get yourself a disassembler and start looking! :)