Jump to content

Using XTeVe with Emby


EODCrafter
Go to solution Solved by EODCrafter,

Recommended Posts

horstepipe

Hello fellows,

I'm new to xteve and I really like it.

I do not want to restream so I disabled the stream buffer in xteve.

I added the xteve m3u url in Emby, channels show up and run fine. Unfortunately the urls are not being passed to the clients directly, so they're being streamed through Emby server. I do not want this, is there a way to prevent this behavior?

Edited by horstepipe
Link to comment
Share on other sites

Hello fellows,

I'm new to xteve and I really like it.

I do not want to restream so I disabled the stream buffer in xteve.

I added the xteve m3u url in Emby, channels show up and run fine. Unfortunately the urls are not being passed to the clients directly, so they're being streamed through Emby server. I do not want this, is there a way to prevent this behavior?

 

What clients? How are you determining this?

Link to comment
Share on other sites

Right OK, i thought he was asking the other way around, so sorry, I misread. Emby Theater for windows desktop will play direct if the media format is supported.

 

For our other apps that are installed from app stores, there are no options for this because we can't verify the legality of the content, and we don't want our apps pulling streams from remote domains that might be associated with piracy. That could cause a problem for us in the app stores, so that's why it runs through your Emby Server.

Link to comment
Share on other sites

IPTV is better run through Emby since it is, sort of, cleaned up. Especially with recording.

I do agree that no buffer should be used in xTeVe with Emby, although some people are using the ffmpeg buffer and it seem to work fine. But that is, IMO, just double buffering and another failure point.

Link to comment
Share on other sites

I'm still learning the finer points of Xteve but isn't that what this setting is for or am I missing something?

 

5dc9e1cfd42d3_ScreenShot20191111at23225P

 

Emby already has it's own internal equivalent of that, so by enabling it in Xteve, it is as dcol said, just double buffering and another possible point of failure.

  • Like 2
Link to comment
Share on other sites

Damien_

Emby already has it's own internal equivalent of that, so by enabling it in Xteve, it is as dcol said, just double buffering and another possible point of failure.

Right, wouldn't 'no buffer' best the option? (That's what I use but was playing around it with it when OP posed the question)

Link to comment
Share on other sites

Right, wouldn't 'no buffer' best the option? (That's what I use but was playing around it with it when OP posed the question)

Correct.

  • Thanks 1
Link to comment
Share on other sites

horstepipe

Right OK, i thought he was asking the other way around, so sorry, I misread. Emby Theater for windows desktop will play direct if the media format is supported.

 

 

Emby theater for windows doesn't get the origin url, either. So also with this client the stream walks through Emby.

Link to comment
Share on other sites

Emby theater for windows doesn't get the origin url, either. So also with this client the stream walks through Emby.

 

In many cases it will, but it depends on the characteristics on the source stream.

Link to comment
Share on other sites

horstepipe

In many cases it will, but it depends on the characteristics on the source stream.

may I send you the link generated by my xteve, so you can take a look to make it direct play with an upcoming emby server version?

Link to comment
Share on other sites

Soggybottoms

I have a question regarding the latest version of xteve (v2.x)..

 

So I was previously running v1.4.1 and it worked well, so last night I decided to upgrade to v2.1.. Everything went well with the upgrade, but I noticed that now (unlike v1) when xteve generates the m3u it replaces all the urls pointing them to the xteve IP:port + some random hash.. I'm assuming this is part of the new buffering feature allowing the streams to passthrough the xteve server, but how does one disable this? When I turn off the buffer option in the settings, the generated m3u still has the same links.. This ends up breaking my tvheadend server when all I want is for xteve to pass the original url in the m3u file.. I had to revert back to 1.4.1 but was curious if there was any workaround for this..

 

Thanks!

Edited by Soggybottoms
Link to comment
Share on other sites

horstepipe

Hey

Sounds lin

I have a question regarding the latest version of xteve (v2.x)..

 

So I was previously running v1.4.1 and it worked well, so last night I decided to upgrade to v2.1.. Everything went well with the upgrade, but I noticed that now (unlike v1) when xteve generates the m3u it replaces all the urls pointing them to the xteve IP:port + some random hash.. I'm assuming this is part of the new buffering feature allowing the streams to passthrough the xteve server, but how does one disable this? When I turn off the buffer option in the settings, the generated m3u still has the same links.. This ends up breaking my tvheadend server when all I want is for xteve to pass the original url in the m3u file.. I had to revert back to 1.4.1 but was curious if there was any workaround for this..

 

Thanks!

Hey

Sorry can’t help you but could you please tell me where I can get v1.4.1 as this is exactly what I need to accomplish :-/

Link to comment
Share on other sites

Soggybottoms

Hey

Sounds lin

Hey

Sorry can’t help you but could you please tell me where I can get v1.4.1 as this is exactly what I need to accomplish :-/

 

Were you running xteve on Windows or Linux? If Windows I unfortunately cannot help, but if Linux basically what I ended up doing was I pulled a v1.4.1 docker image off of docker hub and copied the 'xteve' binary from the image.

 

This is where I grabbed the docker image from:

https://hub.docker.com/r/bl0m1/xtevedocker/tags

  • Like 1
Link to comment
Share on other sites

In v1, the provider URL was written to the M3U. In v2, a URL is generated that links to xTeVe. If the buffer is deactivated, the provider URL is sent to the client via HTTP Redirect. If the client can handle redirects, there are no problems.

  • Like 1
Link to comment
Share on other sites

horstepipe

In v1, the provider URL was written to the M3U. In v2, a URL is generated that links to xTeVe. If the buffer is deactivated, the provider URL is sent to the client via HTTP Redirect. If the client can handle redirects, there are no problems.

Yeah but unfortunately Emby Theater doesn't seem to be able to handle it. The stream goes through the Emby server...

Link to comment
Share on other sites

@marmel Maybe provide an option in xTeVe to pass raw URL to client

 

That would only make xTeVe unnecessarily complicated.
Other functions would then no longer be possible:
- activate / deactivate the buffer without loading the M3U would not be possible anymore

 

- There would be no entry in the log when a client starts a stream.
  • Like 1
Link to comment
Share on other sites

ok, it works fine the way it is for me. Maybe still have version 1.x available for those needing it.

by the way, great job with 2.0

Link to comment
Share on other sites

Soggybottoms

In v1, the provider URL was written to the M3U. In v2, a URL is generated that links to xTeVe. If the buffer is deactivated, the provider URL is sent to the client via HTTP Redirect. If the client can handle redirects, there are no problems.

 

Thank you for clarifying. Unfortunately as soon as I tried to add the m3u on my tvheadend server all the muxes it generated immediately failed, and after reading around on the tvheadend forums it appears that tvheadend muxes do not directly support http redirects. Not an issue tho as I was able to revert back to 1.4.1, which works perfect, and I will need to test it out some more. I have been thinking of moving my backend to NextPVR, but I'm not sure if it supports http redirects. Can anyone confirm? I've been mainly looking to try out v5 on the Linux platform once it moves out of beta.

 

Knowing that there is an option now to pipe to ffmpeg in xteve I would just get rid of my backend completely (I only really need it for Kodi access for Live TV), however I also incorporate my security cameras in my guide and they require seperate ffmpeg parameters than the other channels I add into the m3u. Would it be possible in a future release to allow us to create multiple ffmpeg parameter profiles and allow us to use them on a per-channel basis?

 

Appreciate your time and dedication on the xteve project. It's really a great piece of software.

 

Thanks!

Link to comment
Share on other sites

  • 3 months later...
pir8radio

@@EODCrafter

@@marmei

 

Im starting to give in and play around with XTeVe (since i have a feeling when emby does get this going it will still be lacking at first which is expected) I just cant wait any longer.....   

 

Anyway, I'm finding some holes, that are probably just me not knowing the software well enough yet..    Like with buffering off....   I dont see a way to combine multiple of the same providers into one m3u.  Like i have three providers that all provide "fox 32" each provider allows "4 concurrent streams"   How do I get it to show  ONE "fox 32" channel in emby that allows 12 concurrent streams,  how does XTeVe know when the first 4 are used to start using the next 4 (or next tuner)?    

 

Another hole, how can I set my groups to specific channel numbers without manually editing each and every channel number in that group...   For example I want PPV's to be 6000 up I want movies to be 3000 up, and regular channels to start at 1 and go up from there...   

Edited by pir8radio
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...