Decompiling Placeshifter JAR???

[maninblack_30]

Just wondering what the chances would be of decompiling the Placeshifter JAR file (Which isn't obfuscated) and reversing the protocol to perhaps use something like a Raspberry Pi (which ships with JAVA I believe) as a really cheap extender?

Perhaps if this thread remains, that could be considered a sign that we could do this without upsetting Sagegoogle?

Just a thought ;-)

Fraser

[tmiranda]

Wow, that would be very cool. It's above my Java pay grade but perhaps Slugger, Sean or one of our other Java guru's could take this on?

[stuckless]

Decompiling the Jar is pretty trivial. I've done it a number of times to review different things. (I used it to reverse engineer the placeshifter discovery code at one point).

I've used both JAD and the newer JD (http://jd.benow.ca/).

Neither will produce a set of java files that can be recompiled, but it does give enough of an idea that you can read the code.

The problem with decompiled code, is that you don't get the "original" code that includes comments and variable names (non public ones) are just assigned letters, like ,'a1' 'a2', etc, and this can make reading it somewhat tricky.

I did start to look at "how" the placeshifter works, but I didn't have the time to dedicate to really understanding it. (The past year, has been a very busy year for me...)

[Slugger]

I'm intrigued, and like stuckless, I've decompiled the jar before. I've decompiled the server jar to learn somethings about the server side in the past as well.

But this, to me, falls under the same category as the ongoing effort by others to raise cash for an XBMC pvr plugin against Sage -- it'll get done if/when someone with the know how needs/wants the functionality. I hope they do, but I doubt they'll raise enough cash to pay someone to write that client. But if a user with the skill set ever wants/needs that client then that's when it'll get done.

I think with enough desire, I could probably deduce the placeshifter protocol based on the decompile of the jar, but that's the key -- I don't have the desire to actually do it. Why? Because it's a lot of work & I don't need to do it. I have extenders at my tvs and I have a stockpile of extenders in the office closet to replace those extenders and so I just don't need the functionality. If I ever do, well then that's when I probably start looking closer at it.

With that said, my interests would lie exclusively in the communications & data structures. The graphics and A/V requirements... no interest to me what so ever so I'd only be able to bring but a small piece of what's required.

Anyway, in short, you need to find someone (or a group) of people with the skill set and the need for the functionality this work would provide. Find that and you're good to go. Until then, I don't think there's anything here other than knowing it's probably possible that someone could do it, which I suppose is better than nothing.

[maninblack_30]

Originally Posted by Slugger

Anyway, in short, you need to find someone (or a group) of people with the skill set and the need for the functionality this work would provide. Find that and you're good to go..

I guess that is exactly what I'm hoping for - something that would provide me with a secure future with SageTV - as there still isn't anything that comes close for me - for me it's the extenders, and the lack of maintenance they require and the flexibility they provide, heck, my 6yo doesn't understand what "normal" TV is, and gets annoyed at other houses when she can't watch what she wants! ;-) I'd be more than happy to chip in money wise, but I have no programming skills at all.

Cheers,
Fraser

[Slugger]

Money doesn't matter on things like this, imho. But if you're willing to pay for an alternate client solution for Sage then, as I said, there's an ongoing effort to raise cash for an XBMC plugin (more details thru out this thread). But that doesn't look very promising (91% shy with 4 weeks remaining).

If it were strictly about money then there wouldn't be enough users to pay the actual development costs of such a solution. That's always been my thoughts and that kickstarter project above is confirming it. But lucky for us, these types of things don't get done for money. Unlucky for us, they get done by people who 1) know how to do it and 2) need the functionality and that group, unfortunately, has diminished quite significantly over the last couple years.

I'm stockpiled in HD200s and hopefully won't run into any issues, but trust me, if someone came and took all my extenders tonight, you'd have that XBMC plugin ready to go within a few weeks.

[stuckless]

I agree wit Slugger here, as well. The things that are done for SageTV are largely done out of necessity, and not for monetary gains. And right now, a lot of sagetv developers have lots of extra hardware, etc, and the necessity just isn't there. My biggest concern isn't about what I could use as an extender, but what am I going to do when I can no longer run a SageTV server (for whatever reason).

So, in a year or two, after a few more electrical storms (I've lost extenders during electrical storms ) I might have a greater need to do this

[Slugger]

It randomly popped into my mind yesterday while I was out and about that if nothing else, deducing the placeshifter protocol would probably allow an external client (like the XBMC plugin -- or really just about anything) to register with the Sage server and obtain a Sage UI context. This would presumably allow a live tv implementation on these third party solutions to occur with a much greater chance of success. With a Sage UI context, you can now call the various live tv api calls. I'm not sure if it's quite that easy because maybe the UI context must consume the a/v stream as part of the protocol, but if not then you can just register as a UI and consume the live recording outside of the placeshifter connection. Anyway, just some food for thought for anyone who comes reading in here.

[Brent]

I don't currently have a need for this, but I hope someone does it. Certainly has a lot of potential!