Page 2 of 4
Re: [App] Recording Title Patch D/E/F/H
Posted: Sun Feb 08, 2015 11:18 am
by zoelechat
@mikemcgear
Be sure to have set FileZilla to "binary" transfer mode, and re-transfer both samyGOso and libRecTitle.so
Re: [App] Recording Title Patch D/E/F/H
Posted: Sun Feb 08, 2015 11:23 am
by juusso
latest 1.2.4 version of samyGOso is included to samyext4.img by default.
Re: [App] Recording Title Patch D/E/F/H
Posted: Sun Feb 08, 2015 12:26 pm
by zoelechat
juuso wrote:latest 1.2.4 version of samyGOso is included to samyext4.img by default.
Ok, I wondered, "segmentation fault" would have been shown earlier if not. So I even more suspect it's due to bad transfer type of libRecTitle.so
Re: [App] Recording Title Patch D/E/F/H
Posted: Sun Feb 08, 2015 3:59 pm
by mikemcgear
Thanks for confirming this.
I have now tried again after rebooting the TV, and now it also works here on my UE48H6600, T-GFSDEUC 1210.5
I have NOT uploaded the lib again, so it was OK and binary transfer all the time. Thanks for all the suggestions, though.
# samyGOso -d -A -B -r -l /mnt/opt/privateer/usr/libso/libRecTitle.so MINUTES_TO_ADD:10
samyGOso v1.2.4 (c) bugficks 2013, sectroyer 2014
Injecting '/mnt/opt/privateer/usr/libso/libRecTitle.so' resident: '1'
mprotect: 0x4227c020
dlopen: 0x424a0d80
dlclose: 0x424a0e14
dlsymaddr: 0x424a0e78
pc=42324eec lr=42324ed0 sp=bdc8a150 fp=d902468
r0=d90246c r1=80
r2=1 r3=0
stack: 0xbdc6a000-0xbdc8b000 length = 135168
executing injection code at 0xbdc89ffc
library injection completed!
Succeeded.
Re: [App] Recording Title Patch D/E/F/H
Posted: Fri Feb 13, 2015 3:24 pm
by tempinbox
what about C series?
Re: [App] Recording Title Patch D/E/F/H
Posted: Fri Feb 13, 2015 5:35 pm
by sectroyer
tempinbox wrote:what about C series?
In theory it should work but I dropped C support
Especially for such complicated patches
Re: [App] Recording Title Patch D/E/F/H
Posted: Wed Feb 18, 2015 2:08 pm
by mikemcgear
I have been using this patch for a while now and while it basically works, I also face reboots of the TV.
What I noticed so far is this situation:
Setting: MINUTES_TO_ADD:10
Making a recording of just 5 minutes total length (for example weather forecast) will make the TV unstable and might trigger a reboot.
Is this situation handled correctly in the code?
What would be a proper set of settings to avoid the issue?
Thanks,
Mike
Re: [App] Recording Title Patch D/E/F/H
Posted: Wed Feb 18, 2015 2:51 pm
by sectroyer
mikemcgear wrote:I have been using this patch for a while now and while it basically works, I also face reboots of the TV.
What I noticed so far is this situation:
Setting: MINUTES_TO_ADD:10
Making a recording of just 5 minutes total length (for example weather forecast) will make the TV unstable and might trigger a reboot.
Nice
mikemcgear wrote:
Is this situation handled correctly in the code?
No
mikemcgear wrote:
What would be a proper set of settings to avoid the issue?
Simple. Don't MINUTES_TO_ADD to LESS than shortest recording you schedule
Re: [App] Recording Title Patch D/E/F/H
Posted: Wed Feb 18, 2015 5:28 pm
by mikemcgear
sectroyer wrote:mikemcgear wrote:I have been using this patch for a while now and while it basically works, I also face reboots
mikemcgear wrote:
Is this situation handled correctly in the code?
No
mikemcgear wrote:
What would be a proper set of settings to avoid the issue?
Simple. Don't MINUTES_TO_ADD to LESS than shortest recording you schedule
Well, this I cannot do. I regularly need 10-15 minutes earlier recording time to make sure to catch the actual transmission that I want to record. Usually during the night the schedules are not very reliable on some programs.
Are you considering adding some code to handle this? Are you able to get the total time of the recording via API?
Thanks,
Mike
Re: [App] Recording Title Patch D/E/F/H
Posted: Wed Feb 18, 2015 5:35 pm
by sectroyer
mikemcgear wrote:
Are you considering adding some code to handle this? Are you able to get the total time of the recording via API?
Not now... Besides it's still not clear why do you experience crashes/reboots with "short recordings"... It wasn't reported by anyone else. I checked it here and nothing strange happens with such scenario