I tried the experimental mpeg-ts rewriter - it definitely seems better as some test recordings were good, but I still had some test recordings with issues - for example, I recorded the NBC nightly news (30 min) and it indicated 26+ hours in length - then I manually ran the 2 fixes (timestamp and video index) and it was 30 minutes - are there some encoder settings that I need to change? (Turn off high profile?) - I am currently using MPEG4, high profile, CBR, 10Mbps, Custom 60 fps
My config/environment has been really stable since fixing the remote issue and now I am turning attention to cleaning up the scripts and making things feel less "hacky".
First set of changes is to add a encoder ip and tuner ip to the main.go file so that we(hopefully this will be considered for merging) only need to maintain one set of scripts for multiple tuners/encoders.
Feedback welcome!
1 Like
I'm going to start working on reducing the number of tuning scripts required for the Docker container version of this project. In addition, I want to create an directory structure that makes sense. So, here are my ideas, which I'd like to get some feedback on:
I believe all that's necessary to have a single script work for any tuner is to be able to pass the adb device name as a parameter. Right now the channel name/number is passed as $1, so the adb device name could be the second parameter. Am I missing anything else that might be needed?
Secondly, to support multiple streaming devices and apps, I'm thinking that under /opt/scripts we could organize by device/app/script. Make sense?
Funny. You posted on the same topic at almost the same time! Let's coordinate on this.
1 Like
Have a look at my main.go where I am passing the encoder and tuner ip's.
Also really like the idea of making scripts available via a directory structure.
Since this project does possibly require some equipment purchases, I just wanted to point out that it looks like Amazon has finally announced their Prime Days 2013 for July 11-12. So those of you on the cusp of trying out this project may want to keep that in mind. I know I always get some awesome deals.
Hopefully we will see a FireTV cube deal. This device is excellent.
I'd suggest we use environment variables, which would work both for people who want to deploy using the container and for those that don't. For example:
url: os.Getenv("TUNER1_URL"),
pre: os.Getenv("STREAMER_APP") + "/prebmitune1.sh",
start: os.Getenv("STREAMER_APP") + "/bmitune1.sh",
stop: os.Getenv("STREAMER_APP") + "/stopbmitune1.sh",
Where $STREAMER_APP would be the device/app part of the directory path. For example, firetv/yttv -- how does that strike you?
1 Like
I like it! Maybe create a .env file that is sourced when launching main?
This would also provide a path to cleanup my keep_alive.sh script as well.
EDIT: this looks good GitHub - joho/godotenv: A Go port of Ruby's dotenv library (Loads environment variables from .env files)
That library looks fine, but would create a potential conflict between container users and non-container users as there would be two different methods of setting env vars. In Portainer in particular, it's more convenient to have the environment variables in with the stack rather than in a separate .env file.
Since androidhdmi-for-channels has to be launched somehow by the non-container users, I'd propose the setting of env vars as part of launching the executable (in a script for example).
Maybe we should move this discussion to discord. I see Channels has a discord server with a dev-playground? Official Discord Soft Launch
@bnhf Take a look at the repo now - its using env variables and the new structure. GitHub - sullrich/androidhdmi-for-channels: androidhdmi-for-channels
Regardless of where you collaborate, I'll be eagerly following and learning quickly, happy to test anything you develop and to share notes!
I find all of this inspiring, fascinating and fun.
One extra bit that would be cool to include, if possible, is this code for YTTV subscribers, as apparently it's more reliable than potentially-dynamic URLs for each target channel.
Mine still haven't changed but as I channel surf I wonder, how long will this last? lol
1 Like
I meant to move the developer related discussion to Discord but a lot of the things we are discussing via this thread could also be talked about over there as well. Wondering if we could get a Discord channel named hdmi-channels @tmm1 ?
Nice work -- that looks great, and should lend itself well to either host-based or docker-based installations -- especially at this stage.
I posted some info about that Home Assistant script when it was originally posted. It's out of date and won't be very helpful here.
@tmm1 Can you clarify which license your code is under for hdmi-channels go and shell scripts?
EDIT: the license is MIT in case anyone is wondering.
EDIT: lots of features landed in my repo today including:
Improve script durability / reliability
Allow multiple tuners from one set of scripts
Allowing the tuner and encoder information to be dynamically set. Useful for docker containers, etc
Support for FireTV and Hulu
Please let me know if you use it or have questions!
I'd love to jump in here but the thread is a little too long for newbies. If I were to buy an HDMI IP encoder, and use it connected to an extra FireStick I have laying around, how hard is it to simply record the stream into a Channels?
I'm assuming to manually tune and play a show on the FireStick, I'd need an HDMI splitter (so I can see what I'm doing, and which I also have laying around somewhere).
I'm not sure if I'm ready to dive into all this coding, unless there was one of you interested in summarizing what you have worked out for specific types of sources (such as the FireStick) in a Wiki format or something? I'm ready to spend $$ but it's the time to futz around that I'm lacking.
Some encoders have HDMI out built in so you can do exactly that.
I use VLC on a laptop to see what is going on a bit laggy but works. I can look at all my 4 capture inputs this way.