fuse file system for hdhomerun network tuner

[malahal]

Hi All, Thanks for the wonderful firmware, I tried developing a simple fuse file system for my HDHOMERUN tuner to watch live OTA channels. I created synthetic files for each channel and when some opens/reads that file, I run hdhomerun_config to set to correct channel and start saving to a real file on the disk. Any reads to the synthetic channel file are mapped to the actually saved file. This worked nicely, but it stopped playing as soon as it reached the initially advertised file size. I thought that is how it works, but to my surprise, if I play the saved file on disk, it plays continuously even after the initial file size.

I noticed that the real disk has .wd_tv directory that it keeps for book keeping but the my fuse FS is read only. I made my fuse FS read/write and gave a backing store. Tried replicating the getattr of the "/" of the fuse to the recorded directory. Still no difference. Now, I wonder if wdtv live player uses INOTIFY for this purpose, if so, can I replicate that in FUSE fs?

For now, I just open synthetic channel file and then go back and play the real recorded file. It works, but would love to make the wdtv play the synthetic channel file continuously.

Appreciate any help. I see few threads on using UMSP for this. Maybe, I should try the UMSP route (I need to read up on UMSP plugins and learn some php)

[b-rad.cc]

.wd_tv directory is only made & populated on real / 'officiallly' connected devices and has nothing to do with playback time. Anyways, you're the author of the fuse filesystem, so why don't you say all the file sizes are 30GB if thats the issue?

[malahal]

.wd_tv directory is only made & populated on real / 'officiallly' connected devices and has nothing to do with playback time. Anyways, you're the author of the fuse filesystem, so why don't you say all the file sizes are 30GB if thats the issue?

It did create a .wd_tv directory inside my fuse mount when I made it read/writable with a backing store with two files in it. Regarding the file size, I forgot to tell:

My first attempt was to start with a very large file size (8GB in my case). I tried this fuse fs on Linux and WDTV LIve. The "vlc" application on linux and WDTV Live player, they both try to read few bytes from the middle of the file. The fuse driver returns 0 byte read if nothing is recorded yet at the offset.

"vlc" just ignores it and then starts reading from the beginning and it works just fine. On the other hand, WDTV live complains saying that "media format is not playable..."!!! mplayer on Linux doesn't do this, it just starts reading from the beginning of the file.

I will have to see what happens if I return some "beginning portion of the file" instead of 0 when there is no recorded data at the specified large offset.

[b-rad.cc]

Just because the .wd_tv directories are made doesn't mean anything. That directory is only for media library cataloging.

Fuse doesn't return anything you don't tell it to. You'll need to do a packet using UMSP and one of your homerun files that doesn't stop to see what dmaosd is getting when it asks. There will always be 3 requests for data from any video file that is opened. Usually either two at the start of the file and one at the end, or with some codecs one at the start and two at the end.

[malahal]

Just because the .wd_tv directories are made doesn't mean anything. That directory is only for media library cataloging.

Fuse doesn't return anything you don't tell it to. You'll need to do a packet using UMSP and one of your homerun files that doesn't stop to see what dmaosd is getting when it asks. There will always be 3 requests for data from any video file that is opened. Usually either two at the start of the file and one at the end, or with some codecs one at the start and two at the end.

Thank you for the information. I don't see dmaosd asking anything at the end now, that may be due to the synthetic channel files being named with .ts extension now! The videos play fine by setting a large file size. It seems to read data faster (for buffering, I imagine) than the tuner can produce though. This may be easy to fix by just sleeping in the fuse read API.

Thank you for your responses. Thank you for your work!