[PC] SamyGO PVRDecoder for E/F/H series - Version 1.8.2.53

[Lordbyte]

hi! i have decode arrow on samgo pvrdecoder but when i open the file (srf file) on TSDoctor i can?t open it it says: not a valid transport stream format or stream is encrypted. my antother movies works. i only get a srf file. i record on kanal5 (swedish channel) now i try to decode anather movie but when i open it on tsdoctor it says the same. i have fix it i turn off the tv and turn on then it works

Erhh .. You .. hmm .. What ?

[sailor404]

Hi everybody!
Is there anyone who has the firmware 1114.1 on the TV?
I have tried 100 times. Hack was succesfull (Start Skype/Install Patch via Samygo App/ 1.Ok 2.Ok Restart)
but no telnet connection(Win7 Pro built in or putty) to my german model F6500!
It says "connection is terminated" on ports 23/1023/2023
and ftp 21 no connection. However ping is OK!

Firewall/Antivirus is off!
Telnet to the other devices like Fritzbox, Synology functions on the same home network

I need help!

[sectroyer2]

OK I see, no linux, had to ask because with linux batch scripting is so much easier...
I think you misunderstood, don't want a backport for older tv series, just a linux command-line tool for this one for automation

Well, the needed modules are public due to Bugficks.

Why dont you just ask the needed questions, and script the stuff yourself.
You seem bright .. Support the SamyGO community by releasing Linux-tools !

I am bright too:P Anyway I have working linux tools and would like to release them but I need working version (for any system) of drmdecrypt. For now my tools use windows version of drmdecrypt used by samyGOPVRDecoder and that's why I am still working on it. Please point me in a right direction:)

[bugficks]

i doubt its of any use but there you go

drmdecrypt.zip

it depends on some trucecrypt files and intel aes lib.
i know about sync lost tracking across buffers limitations but this thing started to proof another dev here wrong who insisted that x64 is faster than x86 which somehow ended up in this tool

[Lordbyte]

... but this thing started to proof another dev here wrong who insisted that x64 is faster than x86 which somehow ended up in this tool

Wohoo - I made a difference in this instance of the universe

Now, if I tease you about not being able to do a EPG/Scheduler .. Will you prove me wrong on that point too, please ?
Besides, you being so damd clever ought to be able to utilize the double buswidth in a x64-process to decode
even faster .. I mean, - my SSD has brief moments of boredom

[bugficks]

double bus width != double bus band width
on x64 instructions are bigger, pointers are twice as big. hw caches etc are same, now guess in which mode you can cache more:)
x64 really only make sense if it comes to memory management.
if at all it would make more sense to use more threads
about epg, as i said before ask arris for soap/upnp/dlna or search forum. i dont have possibility here nor the mood for epg

[F6500]

I'm having trouble decrypting the recordings. Everything worked great until today.


EDIT. Reboot TV solved the problem.

[sectroyer2]

i doubt its of any use but there you go

drmdecrypt.zip

it depends on some trucecrypt files and intel aes lib.
i know about sync lost tracking across buffers limitations but this thing started to proof another dev here wrong who insisted that x64 is faster than x86 which somehow ended up in this tool

Thank you very much I will try to port it to *nix systems

[Lordbyte]

double bus width != double bus band width

I dident say so either .. I said "utilize" .. A benefit in performance MUST be possible.

Your code must at least in theory be able to benefit from saved memory-access cycles,
if you are served a 64-bit datastream to CPU and just consider registers 32-bit, and then
"simply" replace every even/odd fetch-cycle with a register high-order-32bit to low-order-32bit register-swap.

on x64 instructions are bigger, pointers are twice as big. hw caches etc are same, now guess in which mode you can cache more:)
x64 really only make sense if it comes to memory management.

The amount of cache you would want for the decoder can hardly be in the order of > 4Gb .. right ?
Up to that point pages have single entry in TLB, pending granularity-bit, right ?
So, we win nothing regarding hardware memory management, unless you feel like allocating more than 4Gb.
Anyway .. who cares about memory, if you can have raw speed .. wrooooooom

Notice, this is/was just for the sport of thinking x64 .. your current DRMDecrypt implementation is blindingly fast .. amazing work .. I just want to push you over the top

[bugficks]

thats about the only thing you can do, trying to squeeze 2x32bit instruction in one 64. anyways, thats not worth the effort/time/insert random reason. also the aes code which i guess is the hotspot is already optimized asm or hw accelerated
TLB doesnt matter at all, i dont do alloc/free but having 2 big buffers. there are far more important caches. 1st,2nd level, branch prediction, etc. and those are fixed size regardless if x86 or x64 mode.
i was talking about os memory management. e.g. it's faster to locate free mem chunks in x64 vm address space (16TB iirc) than in 4GB.
64 bit really makes not much sense performance wise for 99% of all apps