When using a M3U - Does the client or emby server communicate with stream?

[Carlo 4330]

@@ebr, you need to read further or just ask Amazon. They do not monitor apps the way you think they do. In a nut shell they only pull data that interacts with their own services.

 

Examples of Information Collected

Information You Give Us

You provide most such information when you search, buy, post, participate in a contest or questionnaire, or communicate with customer service. For example, you provide information when you search for a product; place an order through Amazon.com or one of our third-party sellers; provide information in Your Account (and you might have more than one if you have used more than one e-mail address when shopping with us) or Your Profile ; communicate with us by phone, e-mail, or otherwise; complete a questionnaire or a contest entry form; use our services such as Amazon Instant Video; compile Wish Lists or other gift registries; participate in Discussion Boards or other community features; provide and rate Reviews; and employ Product Availability Alerts, such as Available to Order Notifications. As a result of those actions, you might supply us with such information as your name, address, and phone numbers; credit card information; people to whom purchases have been shipped, including addresses and phone number; people (with addresses and phone numbers) listed in 1-Click settings; e-mail addresses of your friends and other people; content of reviews and e-mails to us; personal description and photograph in Your Profile ; and financial information, including Social Security and driver's license numbers.

Automatic Information

Examples of the information we collect and analyze include the Internet protocol (IP) address used to connect your computer to the Internet; login; e-mail address; password; computer and connection information such as browser type, version, and time zone setting, browser plug-in types and versions, operating system, and platform; purchase history, which we sometimes aggregate with similar information from other customers to create features like Top Sellers ; the full Uniform Resource Locator (URL) clickstream to, through, and from our Web site, including date and time; cookie number; products you viewed or searched for; and the phone number you used to call our 800 number. We may also use browser data such as cookies, Flash cookies (also known as Flash Local Shared Objects), or similar data on certain parts of our Web site for fraud prevention and other purposes. During some visits we may use software tools such as JavaScript to measure and collect session information, including page response times, download errors, length of visits to certain pages, page interaction information (such as scrolling, clicks, and mouse-overs), and methods used to browse away from the page. We may also collect technical information to help us identify your device for fraud prevention and diagnostic purposes.

------------

One key element I think being missed here is that routing info through a server vs just allowing access directly will make no difference to these store companies.  If you condone pirating then it doesn't matter the method.  If anything they could see the server used this way as obfuscating it which is probably worse.  With that said, this isn't the type of app that these companies go after.  If on the other hand if Emby came out of the box with 1000 illegal IPTV channels then it would be another matter.

At the end of the day, this is a developer decision and not a user decision of course and if in doubt then you err on the safe side.

[EODCrafter 180]

In the End, it will be the End-User that takes it in the Arse...as usual. Maybe sometime in the future IPTV will become more Main-Stream instead of a backroom topic. I suppose with Net Neutrality gone, they can do whatever they want.

Edited October 9, 2018 by EODCrafter

[pir8radio 1292]

Emby doesn’t want to turn into a Kodi. You ask people what they know about Kodi and the first thing they probably say is "free TV" or  "free movies". I’ve seen a few articles lately where Kodi is trying to get rid of apps like that and bring their name back, they’re Trying to take a similar stance now as Emby has been all along. But you can’t recover from that, it’s kind a like Jared from the Subway commercials do you think of sandwiches or a peddi?

The play stores may not actually monitor Real time but they test each version of the app prior to Putting it in the store so there’s no sneaking it by.

Again I think it should all go through the server anyway.

Edited October 9, 2018 by pir8radio

[maegibbons 1267]

Hi

 

I have no problem with external IPTV streams going through the server - in fact I prefer it as it limits bandwidth to one stream even if two are watching internally.

 

What I have an issue with is why my Fire TV cannot direct play directly from my NAS.  Thats my content on my network.

 

Whats that got to do with Amazon policies?

 

Krs

 

Mark

Edited October 10, 2018 by maegibbons

[Luke 37071]

Nothing, it can direct play from your NAS. If you have a question about why something is transcoding, please open a topic about that. Thanks !

[maegibbons 1267]

*sigh*

 

@@Luke You need to get on the same page as @@ebr.

 

I have discussed this before and @@ebr says it cant be done. I will try and find the thread.

 

EDIT Here is thread:https://emby.media/community/index.php?/topic/61574-direct-play-items-stop-when-server-shutdown/

 

This is NOTHING to do with transcoding.  I am talking about items that are playing direct being streamed through the server.

 

Currently,  If you play something direct and reboot the server, the playback will be interrupted even though, as YOU state, the stream should be coming from the NAS

 

Perhaps you can decide between you whether it can be allowed and code accordingly.

 

Krs

 

Mark

Edited October 11, 2018 by maegibbons

[ebr 14913]

*sigh*

 

@@Luke You need to get on the same page as @@ebr.

 

I have discussed this before and @@ebr says it cant be done. I will try and find the thread.

 

EDIT Here is thread:https://emby.media/community/index.php?/topic/61574-direct-play-items-stop-when-server-shutdown/

 

This is NOTHING to do with transcoding.  I am talking about items that are playing direct being streamed through the server.

 

Currently,  If you play something direct and reboot the server, the playback will be interrupted even though, as YOU state, the stream should be coming from the NAS

 

Perhaps you can decide between you whether it can be allowed and code accordingly.

 

Krs

 

Mark

 

We consider delivering the completely unaltered file via http through the server "direct" playing because the file is not modified in any way.  Trying to actually deliver it via a different protocol going direct to the file system would increase our troubleshooting much more than the value it would bring to the average user so it simply isn't something we're too concerned with right now.  These boxes are designed to work over http so that is how we are using them at this point.

 

This has nothing to do with Live TV or m3u so this discussion doesn't really belong here.

[maegibbons 1267]

We consider delivering the completely unaltered file via http through the server "direct" playing because the file is not modified in any way.  Trying to actually deliver it via a different protocol going direct to the file system would increase our troubleshooting much more than the value it would bring to the average user so it simply isn't something we're too concerned with right now.  These boxes are designed to work over http so that is how we are using them at this point.

 

This has nothing to do with Live TV or m3u so this discussion doesn't really belong here.

 

Considering the main question in the Title

 

"Does the client or emby server communicate with stream?"

 

It is very related.  You have answered,  Thank you.  I think wasteful use of network bandwidth is a good reason to address this. However, whatever you feel, it was apparent that there was a difference in understanding between yourself and @@Luke of what you are currently doing in the ATV app.

 

Krs

 

Mark

Edited October 11, 2018 by maegibbons

[ebr 14913]

 it was apparent that there was a difference in understanding between yourself and @@Luke of what you are currently doing in the ATV app.

 

No, this was just a difference in understanding of the terminology.  Luke is fully aware of how the app is behaving but we consider what it is doing to be "direct" playing.

[maegibbons 1267]

No, this was just a difference in understanding of the terminology.  Luke is fully aware of how the app is behaving but we consider what it is doing to be "direct" playing.

 

If you say so - but I dont think so.

 

Tell me - what does the non-store version of Emby Theatre do?  It appears to PROPERLY direct play from the NAS.

 

So lets not just pay lip service to conformity between the apps.  Bring it to ATV Like it is in ET

 

Krs

 

Mark

[ebr 14913]

Tell me - what does the non-store version of Emby Theatre do?  It appears to PROPERLY direct play from the NAS.

 

Theater desktop is a PC app.  PC file sharing over the network is a well-established and, dare I say, necessary protocol we can assume will be in place.

 

From a streaming box we cannot make that assumption.  File sharing access over a protocol other than HTTP is simply not normally in place.  The boxes are designed to access content via HTTP.

 

We may try to support direct file access in the future but its benefits do not currently outweigh the costs (mostly in support).

 

There is one caveat to this, however, and you can test it out if you want.  If you configure the app to use an external player, then there is also an option to pass the direct file path.

[Spaceboy 2493]

so you consider both the ET and the ATV app to be direct playing? even though the methods are substantially different? can you see where the confusion is arising?

[ebr 14913]

so you consider both the ET and the ATV app to be direct playing? even though the methods are substantially different? can you see where the confusion is arising?

 

We consider it "direct" because the file is not modified in any way.  That is the same in both instances.

 

Beyond that is simply a matter of degrees.  Two different protocols for delivering that file.  Should we report different methods when the file is being read via network from the Emby server vs. a local drive?  Should it be different if it is via SATA connection vs. USB?  For the average user, those differences are meaningless.

[pir8radio 1292]

The original question was about IPTV m3u's not playlists with media stored locally right?   I would think the majority of users want to pass all IPTV streams through the server (whatever you call it).  Not have the clients go directly to the stream.  That's just silly, Most IPTV limit how many ip's you can connect with if all of your users are connecting from their devices, your username and PW, if used, is exposed to the client user, you cannot stream share, you can't transcode if needed, you lose all of the benefits of using emby, why not just put a link to the stream somewhere then?

[maegibbons 1267]

Hi

 

I admit to veering slightly from the original topic.

 

No question - External IPTV should all go through the server - you want that from a bandwifth saving point of view and the other reasons you mentioned.

 

The broadened topic was about "internal" streaming from APPS directly from the NAS avoiding doubling the network usage.  i.e. to conserve internal bandwidth.

 

Krs

 

Mark

[maegibbons 1267]

We may try to support direct file access in the future but its benefits do not currently outweigh the costs (mostly in support).

 

There is one caveat to this, however, and you can test it out if you want.  If you configure the app to use an external player, then there is also an option to pass the direct file path.

 

After waiting for ages to get exo working again with Live TV, albeit transcoding, i really want to stick with the internal player.

 

In relation to support,  make it a "super secret" option tied to your premiere key that you have to pay another $99 dollars one off for to unlock the PROPER direct play functionality.  I would pay extra for that and it covers the suppport from those that want to try it.

 

krs

 

Mark

Edited October 11, 2018 by maegibbons

[Carlo 4330]

The "terminology" used is the cause of much discussion it seems to me:

 

It would be better IMHO if things were referred to as:

TRANSCODE - when either video or audio is being manipulated. This could be changing a codec or just the size of video (ie 1080i to 720p) or deinterlacing (ffmpeg is involved)

REMUX - when both video and audio codecs are kept but the package is changed. (ffmpeg is involved)

DIRECT - when the file is used AS IS sent via http.  This would be a player that can progressively display an MP4 or MKV for example.

LOCAL - this is only for apps that have direct access to the file on the local area network.  It is NOT streamed through the server but accessed from the file system.

 

Right now there isn't always a clear distinction between "Direct" and "Local" as I just described.

Edited October 11, 2018 by cayars

[Spaceboy 2493]

The "terminology" used is the cause of much discussion it seems to me:

 

It would be better IMHO if things were referred to as:

TRANSCODE - when either video or audio is being manipulated. This could be changing a codec or just the size of video (ie 1080i to 720p) or deinterlacing (ffmpeg is involved)

REMUX - when both video and audio codecs are kept but the package is changed. (ffmpeg is involved)

DIRECT - when the file is used AS IS sent via http. This would be a player that can progressively display an MP4 or MKV for example.

LOCAL - this is only for apps that have direct access to the file on the local area network. It is NOT streamed through the server but accessed from the file system.

 

Right now there isn't always a clear distinction between "Direct" and "Local" as I just described.

this my exact point. It feels as if devs are knowingly obfuscating and attempting to be a bit cute with their terminology. And no, we don’t care what your competitor does, we would like it right.

[ebr 14913]

this my exact point. It feels as if devs are knowingly obfuscating and attempting to be a bit cute with their terminology. And no, we don’t care what your competitor does, we would like it right.

 

If you want the system to continue to exist then we need to care about market perception.  Sorry.

 

We've beat this dead horse at least 20 times so this is the last I have to say on the subject.

[maegibbons 1267]

@@ebr

 

I am happy to close this out, but please try and give us PROPER direct play when time permits.

 

As a network guy, halving network bandwidth is a major plus and justifies doing this. Using less resources on the server is also beneficial.

 

Krs

 

Mark

 

Sent from my SM-N950F using Tapatalk

[neik 837]

It depends on the app, the media format of the stream, and the supported formats of the app.

 

Emby apps that are in app stores will go through the server. Standalone Emby apps will direct play from the internet when possible to do so.

 

Just for confirming: If I am using an m3u for LiveTV the following clients...

 

- Emby for FireTV

- Emby for Android

- Emby for iOS

 

...communicate with the server and the server communicates with the provider, correct?

[Luke 37071]

Correct.