SenexCrenshaw
What is next?
I am debating what the next steps here should be. I was considering:
- A UI rewrite with something like Vue.JS
- The backend probably could use some work and porting to C# is interesting as well.
- Name change??
I would separate the two systems (frontend/backend). I think these two will allow other features to be added more easily. Things like channel failover #47 and #38
I am fine with the way things are since it works but I am always considering new ideas that might help y'all out.
I decided to create a new repo. It will use c# in the backend for the server/api piece and VUE JS3 for the front end. I will keep updating this repo as bugs come in.
With the new application: Virtual hdhomeruns with individual channels. Multiple channels can be grouped together for additional viewing connections/failover EPG data can be selected per channel.
This should give lots of flexibility and a new UI will be welcomed.
things are moving along nicely. I have a decent backend written in .net core c# and the UI in react (TS). The plan is to allow uploading whatever amount of M3U/EPG files. From there you can allocate any channels from the EPG files to any amount of HD Home Runs. It will try to match channel names in M3U files for failover and what not. It should be very flexible. No idea when I can get an alpha out to play with but I am pecking away!
am relative new to xteve and iptv in general, but how would the channel failover work ? (it sounds like a nice thing to have since this way is just one channel showing but it will switch/failover if it goes down (all in the background)?
a little late to the party, is the switch to c# and react a personal preference or based on technical issues with go? too bad about the choice of react over vue though ;) anyway, will you share the new repo before the alpha? WIll the failover work with all these ppv channels that changes names and appears dynamically on a daily basis?
Plugging away here when I have free time. I am working out how to handle multiple EPGs/Channels and the UI. I have taken this time to learn React so this is taking longer than I thought. I would very much like a beta out this year and am trying my best to make that happen.
am relative new to xteve and iptv in general, but how would the channel failover work ? (it sounds like a nice thing to have since this way is just one channel showing but it will switch/failover if it goes down (all in the background)?
It would need to be proxied/buffered through the server so when a backend stream fails it will use the other stream. I plan on adding in statistics for this as well so we know how the channels behave.
a little late to the party, is the switch to c# and react a personal preference or based on technical issues with go? too bad about the choice of react over vue though ;) anyway, will you share the new repo before the alpha? WIll the failover work with all these ppv channels that changes names and appears dynamically on a daily basis?
With out starting a serious debate... C# is a personal preference since its so easy and portable now-a-days. VS Code/Studio are solid IDEs.
I am a huge VUE fan as well. I decided to go React since a lot of people out there know React and it was another framework for me to learn. I have been happy with react/redux so far. You could re-write the UI in anything you would like. The server is c# asp.net core and the frontend can be anything.
Once I get the HDHRs worked out, the buffer mechanism and cleanup I will share.
"WIll the failover work with all these ppv channels that changes names and appears dynamically on a daily basis?" . You can create channels that will use those streams. Like you said though they are random... Maybe a feature where we can do regex matching for streams? Dunno. I would have to look into that. The bigger questions is the EPG for these.....
You could re-write the UI in anything you would like. The server is c# asp.net core and the frontend can be anything.
Great! Looking forward to your first release
Is there also a docker version coming :)?
Good luck on the rewrite of the app. Looking forward to it.
Another piece that I was avoiding was any kind of dB for the backend. I am using flat jsons files for storage which added a lot of time in developing. After all of that I still might just go with sqlite.
I plan to only publish docker images for releases.
I use openapi v3 as well so creating clients for the api is very easy.
I'll get back to it and send an update in a week or so.
C#? *covers*
Hmm, such a pity that it is your personal preference... especially because your Go fork worked so flawlessly for me! Thanks for doing that, BTW.
Moving on...
Would love to know how it's been going. Also, wouldn't it be nice to have a discord or some kind of community chat where we can discuss ideas if you want to totally redo xteve and basically create a new project ?
C#? *covers*
Hmm, such a pity that it is your personal preference... especially because your Go fork worked so flawlessly for me! Thanks for doing that, BTW.
Moving on...
I hear ya!
Would love to know how it's been going. Also, wouldn't it be nice to have a discord or some kind of community chat where we can discuss ideas if you want to totally redo xteve and basically create a new project ?
I like this idea. I have gotten a little backed up with life but will try to get something out soon. I am treating this first iteration as a poc and will share when things work at the basic level. It's close. Cool thing you don't even need a UI. Everything can be done with the command line or whatever client you like to code in.
My goal is a poc by end of the first week in January. Assume festures will be missing. My goals for the poc are:
Multiples M3U files Multiple EPG files Icon caching HDHRs will have a collection of channels and associated EPGs/programmes and tuner count Buffering in code not using external programs Statistics around channel usage, Dropped connections, Fail over, Usage...
After that we all will have to start a feature list....
After that we all will have to start a feature list....
Does GitHub have polls? 🤣
Hi @SenexCrenshaw ,
What will happens with the xTeVe when you will start with the next project? Any idea of which xTeVe fork will be the best mantained? I put this question because I want to use xTeVe only for managing my M3U playlists. So I'm not interested on the Plex/Emby support nor the HDHR emulation.
Not sure of the forks out there. I'll patch the buffer bug in my existing one soon.
Not sure of the forks out there. I'll patch the buffer bug in my existing one soon.
Then I'll continue supporting your xTeVe almost for simple patches? And you'll accept PRs from other users?
if i had a wish, i would get a failover / fallback stream and a regex mapping config on import m3u list m3u -> regex like ~das.*erste(.?HD) -> channel group "Das Erste HD" (list1:channel2, list2:channel4 etc) channel group are mapped to xmltv
It would be nice to create groups based on the title of the stream. My m3us do not have any groups but they have prefixes like [AR] or :US:. If based on that prefix we can create groups, it could help tons !
Great suggestions. I was hoping to get a POC out this week, but it is just impossible. I haven't written a line a code in weeks. You know how it is... life and what nots.
My goal is to start up again next week. In the meantime, we can discuss these features. I want the new program to handle more than an HDHR emulator.
I believe a channel is a collection of M3U streams, an icon and an EPG. The collection of streams would be used for failover, but do we ever envision a channel that switches streams after a program? Maybe even with a custom EPG....
I want other IPTV programs to use it including the front-end UI.
@lars18th I use xTeVe for the same thing and want more flexibility.
Hi @SenexCrenshaw ,
Perfect if you wish to discuss some functionalities before starting to code a new project!
From my point of view the suggestions for a new project are:
- Remove the HDHR emulation functionality (almost as a central point). My objective is to use the tool as a MANAGER of M3U playlists. In my case, the playlists (in plural) will come from SAT>IP and HDHR tuners. So I want to centralize the: channel scanning, the channel ordering, the metadata editing (picons, xmltv ids, channel ordering, etc.), EPG management (xmltv sources), automatic update of the playlists, etc.
- Daemon functionality with native multiplatform support (Linux/Windows/Android plus x86/ARM architectures) and with docker support.
- CLI and HTTP-GUI support.
- Support for plugins and/or scripting.
These are all of my wishes. But I'm sure that they are complex. What is your point of view?
Its a good list. I was using xteve for basically the same reasons you are.
#1 I agree with except the proxing part. Ill still add that
#2 Its .net core which runs on those arcs, dont forget macs. Docker is what i develop for
#3 yup. i use openapi V3 so you can make a TON of clients for the API
#4 Something i would look into l8r.
I have actually put some time into this over the weekend. Its not very complicated to do but I took this opty to learn a few new frameworks so it has slowed me a little.
Thanks for the feedback!
Hi @SenexCrenshaw ,
I hope you'll open soon the repo of the new project. And regarding the project name: do you have considered one? Perhaps xTeVe++?
HI @SenexCrenshaw
I can't wait for your new repo to be released.
best reagards
The part where you can manage your EPG is so important, Xteve is pretty clunky and lacks a lot of features in that department.