SamyGo Extension Pack modified for NFS recording
Re: SamyGo Extension Pack modified for NFS recording
hi
i have a little problem activating PVR over NFS on my D6
i have applyed hospitality hack, so i have SamyGo Widget on the TV memory, not on a USB drive
It seems that its mandatory to exec samygo from the same USB drive where you store the xfs image. Im correct?
If i have to exec the USB hosted sammyapp, how can i do?
If its no mandatory, what i have to do to reference the XFS image on the init scripts?
i have a little problem activating PVR over NFS on my D6
i have applyed hospitality hack, so i have SamyGo Widget on the TV memory, not on a USB drive
It seems that its mandatory to exec samygo from the same USB drive where you store the xfs image. Im correct?
If i have to exec the USB hosted sammyapp, how can i do?
If its no mandatory, what i have to do to reference the XFS image on the init scripts?
- beatfreak
- SamyGO Project Donor
- Posts: 591
- Joined: Tue Aug 23, 2011 9:03 am
- Location: Hamburg
- Contact:
Re: SamyGo Extension Pack modified for NFS recording
hi everybody,
as i currently only have a 1G usb pendrive available i thought of mounting a nfs share containing the xfs-image so that the structure would look like
directory with xfs-image
(via nfs mount of exportA) in your suggested solution this would be on already mounted usb drive
..virtual XFS USB Drive
..(via mount of xfs-image)
....recording dir
....(via nfs mount of exportB)
the question ist if it would produce double traffic for recording as the chain goes tv-server-tv-server..?
btw.
i had a look at current init scripts in unzipped extensons folder with 80_80_record_to_nwshare.init.kayaweed included
the xfs image will be created during execution but i cant find any point where placeholder file will be created, it only gets checked for existance..
and i'm not clear about the record_to_nwshare scripts (the ".init" and the ".init.remi71") version, the script content is so completely different that i think both of them have to be executed, but as only one of them has the extansion .init this won't be the case... or is there a point where remi-script is called anyway?
in vusb init script we check if xfs_img is present in samygo dir, but as nfsmount script will be called later there will be no image available at this point...(if my xfs_img is located at a nfs share)
now i could
a) change the order of script execution so that nfs mounts happen before vusb execution --> wont work since nfsmount relies on a vusb drive to get its mountpoints...
b) after nfsmount script recall vusb script ??
c) copy pvrimage check-code from vusb script to nfsmount script and have it executed after successful mount
d) ignore the "pvrimage not present - record over nfs won't be enabled" message
meanwhile i bought a 4G pendrive and nfs recording is working fine (speedtest with dd gets about 9MB/s but Samsung performancetest says its not suitable)
but it would still be nice to have the xfs image available via nfs, then people wo have extensions in TV-flash won't need the pendrive anymore...
as i currently only have a 1G usb pendrive available i thought of mounting a nfs share containing the xfs-image so that the structure would look like
directory with xfs-image
(via nfs mount of exportA) in your suggested solution this would be on already mounted usb drive
..virtual XFS USB Drive
..(via mount of xfs-image)
....recording dir
....(via nfs mount of exportB)
the question ist if it would produce double traffic for recording as the chain goes tv-server-tv-server..?
btw.
i had a look at current init scripts in unzipped extensons folder with 80_80_record_to_nwshare.init.kayaweed included
the xfs image will be created during execution but i cant find any point where placeholder file will be created, it only gets checked for existance..
and i'm not clear about the record_to_nwshare scripts (the ".init" and the ".init.remi71") version, the script content is so completely different that i think both of them have to be executed, but as only one of them has the extansion .init this won't be the case... or is there a point where remi-script is called anyway?
in vusb init script we check if xfs_img is present in samygo dir, but as nfsmount script will be called later there will be no image available at this point...(if my xfs_img is located at a nfs share)
now i could
a) change the order of script execution so that nfs mounts happen before vusb execution --> wont work since nfsmount relies on a vusb drive to get its mountpoints...
b) after nfsmount script recall vusb script ??
c) copy pvrimage check-code from vusb script to nfsmount script and have it executed after successful mount
d) ignore the "pvrimage not present - record over nfs won't be enabled" message
meanwhile i bought a 4G pendrive and nfs recording is working fine (speedtest with dd gets about 9MB/s but Samsung performancetest says its not suitable)
but it would still be nice to have the xfs image available via nfs, then people wo have extensions in TV-flash won't need the pendrive anymore...
//UE40C6500 @ T-VALDEUC 3011 // rooted manual HotelMode style // PVR to NFS via 18MB on-the-fly sparse XFS //
FYI: you can close your ssh session with SamyGO with
If you can't fix it using dvct tape, you are not using enough dvct tape.
FYI: you can close your ssh session with SamyGO with
Code: Select all
~.
Re: SamyGo Extension Pack modified for NFS recording
Hi All
i modified remi71 init.d scripts and official init.d scripts to avoid the need of the xfs image on usb pen
all i do is installing mofidied g_file_storage.ko to allow custom names of virtual device => viewtopic.php?t=4722&p=35336
and make the virtual device removable in the vusb init script.
I test the mod on my UE40D6530 with firmware 1021.1 and hospitality hack
scheduled recording worked properly
PS : sorry for my english, it s not my native language
i modified remi71 init.d scripts and official init.d scripts to avoid the need of the xfs image on usb pen
all i do is installing mofidied g_file_storage.ko to allow custom names of virtual device => viewtopic.php?t=4722&p=35336
and make the virtual device removable in the vusb init script.
I test the mod on my UE40D6530 with firmware 1021.1 and hospitality hack
scheduled recording worked properly
PS : sorry for my english, it s not my native language
You do not have the required permissions to view the files attached to this post.
- beatfreak
- SamyGO Project Donor
- Posts: 591
- Joined: Tue Aug 23, 2011 9:03 am
- Location: Hamburg
- Contact:
Re: SamyGo Extension Pack modified for NFS recording
hi lexyan,
could you please explain it more detailed?
do you need no xfs image at all or do you have it moved to another location?
and what steps would be exactly necessary to reproduce this patch?
could you please explain it more detailed?
do you need no xfs image at all or do you have it moved to another location?
and what steps would be exactly necessary to reproduce this patch?
//UE40C6500 @ T-VALDEUC 3011 // rooted manual HotelMode style // PVR to NFS via 18MB on-the-fly sparse XFS //
FYI: you can close your ssh session with SamyGO with
If you can't fix it using dvct tape, you are not using enough dvct tape.
FYI: you can close your ssh session with SamyGO with
Code: Select all
~.
Re: SamyGo Extension Pack modified for NFS recording
he mounts xfs image from another nfs share which is mounted before. Means xfs image needed, but not on TV.
LE40B653T5W,UE40D6750,UE65Q8C
Have questions? Read SamyGO Wiki, Search on forum first!
FFB (v0.8), FFB for CI+ . Get root on: C series, D series, E series, F series, H series. rooting K series, exeDSP/exeTV patches[C/D/E/F/H]
DO NOT EVER INSTALL FIRMWARE UPGRADE
Have questions? Read SamyGO Wiki, Search on forum first!
FFB (v0.8), FFB for CI+ . Get root on: C series, D series, E series, F series, H series. rooting K series, exeDSP/exeTV patches[C/D/E/F/H]
DO NOT EVER INSTALL FIRMWARE UPGRADE
Re: SamyGo Extension Pack modified for NFS recording
Hi Beatfreak,beatfreak wrote:hi lexyan,
could you please explain it more detailed?
do you need no xfs image at all or do you have it moved to another location?
and what steps would be exactly necessary to reproduce this patch?
I explain a little :
for my mod to function, yu need the modified version of g_file_storage.ko (viewtopic.php?t=4722&p=35336), it permits to change the name of the virtual usb device.
- in the vusb init script I change the line loading the module with removable=1 and luns=2 (2 virtual usb, maximum 8 possible)
Code: Select all
insmod $MOD_DIR/kernel/drivers/usb/gadget/g_file_storage.ko removable=1 luns=2 model="SamyGo,Recorder"
I load the original vusb image created by the script as usual
Code: Select all
echo '/dtv/vusb' > /sys/devices/platform/dummy_udc/gadget/gadget-lun0/file
- in the record_to_nwshare init script some variables
Code: Select all
# Name of the xfs image file on the server
XFSFILE='xfs_img'
# Remote NFS fileserver for recording
PVRSERVER='192.168.1.250'
# Remote NFS share for recording
XFSPATH='/home/alexandre/nfs_dir'
# Remote NFS share for recording
PVRPATH="$XFSPATH/pvr_record"
Code: Select all
# if xfs_image found on nfs share mount it on second virtual usb
if [ -e "$NFS_PATH/$XFSFILE" ]; then
WriteToLog "Found $XFSFILE on $NFS_PATH try to plug it on removable usb" 1
echo "$NFS_PATH/$XFSFILE" > /sys/devices/platform/dummy_udc/gadget/gadget-lun1/file
in the zip i linked in my other post you find the xfs_img file (1,5Go gziped in 35ko) you must store it in a share on the nfs server
the other files (init script) goes to the TV in the SamyGO folder etc/init.d/
you must modify the script variable in accordance with your nfs shares
mine are :
Code: Select all
Serveur (IP 192.168.1.250) => /home/alexandre/nfs_dir/ -> xfs_img
-> pvrrecord/ -> CONTENT/
-> database/
Re: SamyGo Extension Pack modified for NFS recording
Right now modified g_file_storage.ko is also available for C-series TVs => SamyGo virtual drive MOD
- beatfreak
- SamyGO Project Donor
- Posts: 591
- Joined: Tue Aug 23, 2011 9:03 am
- Location: Hamburg
- Contact:
Re: SamyGo Extension Pack modified for NFS recording
so the way i understand this, the point of renaming the Virtual USB Drive is negligible, we just need to create one more where we later mount the xfs image right after nfs share is accessible. after this the remi71-script record_to_nwshare may run as usual as it only looks for placeholder file in mounted xfs image and then mounts second nfs-share over mounted xfs-image...?
//UE40C6500 @ T-VALDEUC 3011 // rooted manual HotelMode style // PVR to NFS via 18MB on-the-fly sparse XFS //
FYI: you can close your ssh session with SamyGO with
If you can't fix it using dvct tape, you are not using enough dvct tape.
FYI: you can close your ssh session with SamyGO with
Code: Select all
~.
Re: SamyGo Extension Pack modified for NFS recording
it's exactly this, we create a second virtual usb device and mount the xfs image file on it then the script from remi71 takes overbeatfreak wrote:so the way i understand this, the point of renaming the Virtual USB Drive is negligible, we just need to create one more where we later mount the xfs image right after nfs share is accessible. after this the remi71-script record_to_nwshare may run as usual as it only looks for placeholder file in mounted xfs image and then mounts second nfs-share over mounted xfs-image...?
Re: SamyGo Extension Pack modified for NFS recording
BTW: you do not need two USB drives. With "mount -o bind" you need only one. And also you can use original g_file_storage.ko for such solution.
More details: viewtopic.php?f=9&t=4034
More details: viewtopic.php?f=9&t=4034