SamyGO

leikli wrote:
Maybe the decoding is not done by the CPU itself? Even in that case, my TV has double receivers, and should have more decoding power.

Yeah it's possible it's done by some hardware chip and like on MST by CPU and this limits the speed. We have to CONSTANTLY exchange data between the chip and our "dumping tool". I assume that when you watch pvr encoded video this "chip" simply passes data (on much faster bus) directly to screen Anyway that's my assumption

Do you know why I cant record on the stick scrambled channels opened by oscam on my 40f8000? It says imposible to record.It can record just free to air channels.

nickey1234 wrote:Do you know why I cant record on the stick scrambled channels opened by oscam on my 40f8000? It says imposible to record.It can record just free to air channels.

because:

oscam E/F wrote:known limitations:

• no recording
• no timeshift

Lordbyte wrote:

sectroyer wrote:That was the "faster" version? If yes than my "speed up" won't help much

I am not sure I understand you.

I obviously have no clue as to the internal electronics of the TV?s,
but it seems to me that some H-models decode faster than FTP-session
can move data, and thus the process can run in parallel successfully.
Just like the observations both you and I made on each our TV?s.

We thus concluded that it was safe to assume that the decoder would be
faster than FTP-transfer on EVERY H-model. This assumption seems to fail
for several users (TV?s). Once the process is serialized the process works for those TV?s too.

What makes those TV?s so special I have no clue, but processing-power would be an obvious suspect on the affected TV?s.

Why not use UDP instead it should be faster than FTP as it doesn't include error checking / correction packets.

Is there any chance to remove these limitations? THX!

q8v08 wrote:Why not use UDP instead it should be faster than FTP as it doesn't include error checking / correction packets.

That would make the problem even worse, as the problem is that the FTP-sesstion is "too fast" ... or TV-decoding process is "too slow".

Also, UDP allows loss of packets wich is no real problem real-time, but if you need to pass a COMPLETE file to a second-stage decoder,
you cannot allow breaks in the ts-stream as you rely on certain markers and ..uhmm.. signatures in the file to be decoded.
Those might be missing using UDP .. worst case.
This is the scenario for E(S)- and F-models .. and to re-use code (very popular thing for developers to do), the H-model is of cause using FTP too

Also, I would have no clue how to implement this .. Does TV (SamyGO) even support UDP in this manner ?

nickey1234 wrote:Is there any chance to remove these limitations? THX!

Wrong thread, - there is a thread for Oscam !

Hi,

I have been trying to run 1.7.3.31 against UE48H6600, T-GFSDEUC 1210.5 with limited success. Decode seems to fail.
Observed scenarios include:
- No .ts file is generated on the PC
- .ts file of approx 200 KB is generated
- TV reboots

I tried with and without HW decode switch.
Where should I look at first?

Hi everybody,

my first post here

I just installed SamyGo on my new 40" Samsung (UE40H6200 - T-MST14DEUC-2130.0). Installation seems fine (Telnet port 23 and FTP port 21 do work).
I ran into the following problem when trying to decode a recording using PVRDecoder Version 1.7.3.31:

Connecting to 192.168.1.11:21 .. Success
Querying recordings on TV ...
Verifying telnet access to 192.168.1.11:23 .. Success
All recordings on USB listed. Waiting for user.
Examining DRM status for file ...
Recording is DRM protected
Uploading decoder library to TV
Removing any old work log
Starting the decoding process on TV
Waiting for TV to produce feedback ... 00:00:04 seconds (max. 5 sec.)
UnDRM.log never seemed to appear in /dtv .. 5 second timeout expired. Cannot continue.
Process FAILED somewhere down the road for 20150208182443.srf.
All recordings on USB listed. Waiting for user.
Operation finished .. Waiting for user..

I tried "chmod 755 /mtd_rwcommon/samyGOso" with no effect.

Does anyone have a clue what goes wrong here?

Thanks a lot!

PS. Decoding works fine on my F-Series TV.

Hello
I have the same problem like "mikemcgear" even the same TV with Twin Tuner (UE40H6600 Firmware T-GFSDEUC-1200.2 ,BT-S/G)
I copy the log of PVR Recorde:

Connecting to 192.168.90.21:21 .. Success
Querying recordings on TV ...
Verifying telnet access to 192.168.90.21:23 .. Success
All recordings on USB listed. Waiting for user.
Connecting to 192.168.90.21:21 .. Success
Querying recordings on TV ...
Verifying telnet access to 192.168.90.21:23 .. Success
All recordings on USB listed. Waiting for user.
FTP conection is good
Examining DRM status for file ...
Recording is DRM protected
Uploading decoder library to TV
Removing any old work log
Starting the decoding process on TV
Waiting for TV to produce progress feedback
Retrieved 0 of 1,80 Gb .. 0 Byte ?
File successfully retrieved.
Operation finished .. Waiting for user..
Result: TS File with 200 Kb
I deleted the previus File, and tried it again:
All recordings on USB listed. Waiting for user.
Operation finished .. Waiting for user..
Examining DRM status for file ...
Recording is DRM protected
Uploading decoder library to TV
30s and the TV swithed of and started again
ErrorCode: 0x00010035
Process FAILED somewhere down the road for 20150209160002.srf.
from now on PVR Recorder looks kike it`s busy . The only option is the abort Buton.
if i`m pressing the abort button, PVR Record asks me if i want to abort the Prosses? But there is no actiity at all.

may this is helping to figure out ehat`s going wrong.

I guess if PVR Recorder work`s then it is a great Tool.