Image Processing Problem when using IPv6 addresses

[ebr 16169]

NOTE: This discussion has ben split off, starting from this post: https://emby.media/community/index.php?/topic/89802-emby-for-android-match-androidtv-app/page/97/#findComment-1493379

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

 

On 12/15/2025 at 6:45 PM, Cr8iveLosr said:

Nothing was ever actually fixed. Posters and thumbnails still fail to load when the TV app connects over IPv6, and the consistent guidance from the devs was to use the standard Android app instead, not a fix for the TV app itself.

As noted in those discussions, the error is in a 3rd party library the app uses for image processing so we can't "fix" it short of re-writing how the app handles images - something we simply cannot justify at this time.

Edited December 19, 2025 by softworkz

[Cr8iveLosr 97]

34 minutes ago, ebr said:

As noted in those discussions, the error is in a 3rd party library the app uses for image processing so we can't "fix" it short of re-writing how the app handles images - something we simply cannot justify at this time.

I understand that the root cause sits in a third party library, and that rewriting image handling isn’t trivial. That’s a fair technical explanation.

What’s harder to reconcile is the timeline.

This issue has been known, acknowledged, and repeatedly discussed since around 2020. That’s roughly five years where the outcome for users has effectively been: “use a different app.” At some point, that stopped being a workaround and becomes the de facto resolution.

No one is arguing that a full rewrite is easy. But over a multi-year span, decisions still get made, either to:

• replace a blocking dependency,

• rework the affected path incrementally,

• or officially deprecate the app and state it clearly.

Instead, the Android TV app remains available, largely unchanged, with known blocking issues that prevent some users from using it at all, through no fault of their own. From the outside, it doesn’t feel like an active decision so much as indefinite deferral.

So while the explanation makes sense technically, it doesn’t really change the user impact or the broader concern. After five years, this isn’t about whether something is easy or hard anymore, it’s about whether it’s something the project intends to resolve or not.

Clarity on that would honestly go a long way.

[Guest]

7 hours ago, Cr8iveLosr said:

I’d love to use the Android TV app, but I can’t.

It’s not all about the UI, although I agree the white border is way too bright in a dark room. The real blocker to me is the long standing missing images issue tied to IPv6. 

 

What is the point of using ipv6 only on your network?  

[Cr8iveLosr 97]

9 minutes ago, embaaa said:

What is the point of using ipv6 only on your network?  

I think you’re confused. No one said anything about running an IPv6-only network internally. That can be fixed.

Most of the discussions are about the Global Unicast IPv6 (GUA) address assigned by the ISP. Whether the LAN is dual-stack, IPv4-only, or IPv6-only is a separate issue.

The point is that the ISP is providing a public, routable IPv6 prefix, which results in devices in that household having GUA addresses when speaking to Emby. That’s independent of how someone chooses to design their internal network.

[Guest]

9 minutes ago, Cr8iveLosr said:

The point is that the ISP is providing a public, routable IPv6 prefix, which results in devices in that household having GUA addresses when speaking to Emby. That’s independent of how someone chooses to design their internal network.

So your choosing to use an ISP that doesn't provide you an ipv4 address? 

I'm confused because I have never heard of an ISP doing this till today. 

[Trevor68 70]

same, turned off ip6 in my ISP toolbox, more trouble than it's worth. different countries do things differently though, maybe he can't?

[Cr8iveLosr 97]

Not always a choice..

IPv6 has been pushed to home users for well over a decade. After IANA exhausted IPv4 in 2011, ISPs began large-scale residential IPv6 deployments around 2012–2014. Today, IPv6 with a global unicast prefix is standard on many consumer connections, largely due to IPv4 address scarcity and reliance on CGNAT

 

In any case, this is going too far off topic. Back on track, the main point is that this issue has been reported for over five years. The developers are aware of it, have acknowledged and confirmed it, and ultimately chose not to address it, instead continuing to push an inferior app as discussed over the last 98 pages.

[Guest]

1 minute ago, Cr8iveLosr said:

Not always a choice..

In any case, this is going too far off topic. Back on track, the main point is that this issue has been reported for over five years. The developers are aware of it, have acknowledged and confirmed it, and ultimately chose not to address it, instead continuing to push an inferior app as discussed over the last 98 pages.

It's been reported for 5 years by 2 users of this forum based on your forum thread you linked.

I give the emby devs are hard time but this is kind of ridiculous for you to keep bringing up.  Get a proper ISP not some starlink crap.  The world isn't transitioning to ipv6 anytime soon. 

[Cr8iveLosr 97]

Let’s dial this back to facts and tone.

First, the claim that this has been reported for five years by “two users” is simply incorrect. There have been multiple threads and repeated reports going back to around 2020, not a single discussion and not two people. Pointing to one linked thread does not justify or warrant the conclusion that only two users have raised the issue. Do your own homework.

At no point did I claim this was a rampant issue affecting everyone, nor has this been “kept being brought up.” It was raised in direct response to questions about app limitations and alternative approaches. Responding in context is not the same as repeatedly pushing the same complaint.

The discussion itself is about a known, acknowledged Android TV app bug tied to IPv6, confirmed by Emby staff themselves and documented over several years. That is not opinion, it is on record and fact.

Dismissing the issue because you personally have not encountered it, or because you are only now hearing about it, does not invalidate it. Likewise, reducing the argument to ISP choice or making personal remarks does not address the technical point being discussed.

My position remains straightforward.
The bug exists.
It has been acknowledged.
It has not been fixed, Will never be fixed as neglected to respond by ebr proves.
The practical outcome for affected users has been “use another app” for years.

That is a fair criticism of product direction and communication, regardless of how many users it affects.

Disagreement is fine. Misrepresenting the history of the issue and resorting to personal comments is not.

the more you know...

[ebr 16169]

8 hours ago, Cr8iveLosr said:

My position remains straightforward.
The bug exists.
It has been acknowledged.
It has not been fixed, Will never be fixed as neglected to respond by ebr proves.
The practical outcome for affected users has been “use another app” for years.

Somehow, it appears you are tying the IPv6 issue with the move to the Universal app and they are completely unrelated.  The situation makes total sense in the proper context.

The decision was to stop maintaining two different apps for the two different platforms.  This had nothing to do with this particular image issue.  It just so happens that, since the other app uses a different UI architecture, it is not subject to the issue.

Since the general direction was to move to the other app and that app doesn't have this issue the obvious solution for the very few people who cannot address the issue any other way is to use the other app.

 

[Guest]

12 minutes ago, Dan_Austin said:

 

1.  Any ISP that does not support IPv6 by now, is a crap ISP (mine is a crap ISP, but being rural, no choice)
 

I use the new app mostly.  It has been crashing on LiveTV this week, with no changes to the server or app version, so I have been
using the old app if I get more than 2 exits in 10 minutes.  The guide and color scheme is nicer on the old app, even if the differences
are minor.  

You have this wrong.  The conversation is going that any ISP that doesn't provide IPv4 is crap. Your ISP is fine.  

[Dan_Austin 71]

Since my obviously clear sentence was not obviously clear to all.  ANY ISP THAT DOES NOT SUPPORT BOTH IPV4 AND IPV6 TODAY IS CRAP

 Neither IP stack will be going away anytime soon, so apps/servers should support both.  EBR's response about the value of fixing the issue is
perfectly valid, but does not mean that for a user than needs IPv6 that that app is not broken.  Choice is good, more choice is usually better.

[Guest]

2 minutes ago, Dan_Austin said:

Since my obviously clear sentence was not obviously clear to all.  ANY ISP THAT DOES NOT SUPPORT BOTH IPV4 AND IPV6 TODAY IS CRAP

I just wouldn't say this personally.  IPv6 is not a requirement and anyone without it will see no difference in their network setup. 

[Guest]

@Q-Droid

If you disable IPv6 on your network you will see nothing broken

If you disable Ipv4 on your network everything in existence will be broken.

Please name a single service that is ipv6 only?

Edited December 16, 2025 by embaaa

[Q-Droid 989]

2 hours ago, embaaa said:

@Q-Droid

If you disable IPv6 on your network you will see nothing broken

If you disable Ipv4 on your network everything in existence will be broken.

Please name a single service that is ipv6 only?

We're a long way off from having IPv6 only sites or services on the public internet. IPv4 only still exists and shrinking. But since IPv6 is the current and future standard it shouldn't be ignored and can solve many problems for people on CGNAT service who choose to use IPv4 workarounds instead. An ISP that doesn't offer IPv6 is crap.

 

[bandit8623 213]

4 hours ago, Dan_Austin said:

This thread went of the rails in the last few days, but has been fun reading.  A few thoughts from the peanut gallery-

1.  Any ISP that does not support IPv6 by now, is a crap ISP (mine is a crap ISP, but being rural, no choice)
2.  The new app is usable, but lacking in noticeable ways
3.  The development team appears too small/spread too thin to address issues in a timeframe some customers want
4.  The competition is getting better (should be irrelevant to the topic, but oddly isn't)

I use the new app mostly.  It has been crashing on LiveTV this week, with no changes to the server or app version, so I have been
using the old app if I get more than 2 exits in 10 minutes.  The guide and color scheme is nicer on the old app, even if the differences
are minor.  Since I spend way more time consuming media than browsing for it, the differences do not bug me much.

The Wolphin app discussion suggests that it would be nice if Emby could support a 3rd party ecosystem.  That way the focus can be
on core functionality and allow volunteers to build solutions if the official versions don't scratch every itch.  But I also get that for reasons
(branding/look&feel/license enforcement) it may not be desired to have that ecosystem...

the only reason an isp would add ipv6 is if they are running out of ipv4 addresses.   why spend more money when not needed?  gnat is another story.  but example centurylink(lumen)"quantum" has enough ipv4 addresses still so they dont offer ipv6 native yet.   there are no issues with ipv4 only...  i have not had a single issue getting or using any sites.  so no ipv6 is not needed in all cases.  some cases it is for isps that are out of ipv4 addresses.

Edited December 16, 2025 by bandit8623

[Cr8iveLosr 97]

On 12/16/2025 at 7:52 AM, ebr said:

Somehow, it appears you are tying the IPv6 issue with the move to the Universal app and they are completely unrelated.  The situation makes total sense in the proper context.

The decision was to stop maintaining two different apps for the two different platforms.  This had nothing to do with this particular image issue.  It just so happens that, since the other app uses a different UI architecture, it is not subject to the issue.

Since the general direction was to move to the other app and that app doesn't have this issue the obvious solution for the very few people who cannot address the issue any other way is to use the other app.

 

Need to correct the framing here, because no such implication was made.

The IPv6 image issue was not raised as a causal explanation for the move to the Universal app, the decision was made long before the issue came up, nor was any connection between the two suggested or implied. It came up only because another user explained why they continue to use the Android TV app, and I explained why I cannot, despite preferring it.

That context matters. Replying with bits and pieces of the original message implies rest was thrown out. This thread is about comparing the two clients and understanding their limitations in practice. Explaining why “just use the TV app” is not an option in some cases is directly relevant, not a resurrection of an old issue.

I’m not disputing the technical explanation, asking for changes, or revisiting prioritization. The only point was to clarify my own constraints so the comparison remains accurate.

Anything beyond that is being read into the comment, not stated by it.

[softworkz 5065]

On 12/15/2025 at 6:45 PM, Cr8iveLosr said:

It’s not all about the UI, although I agree the white border is way too bright in a dark room. The real blocker to me is the long standing missing images issue tied to IPv6. This was acknowledged by Emby staff back in 2020 or earlier and has been repeatedly brought up since.

Nothing was ever actually fixed. Posters and thumbnails still fail to load when the TV app connects over IPv6, and the consistent guidance from the devs was to use the standard Android app instead, not a fix for the TV app itself.

I'm not familiar with the actual issue, but thinking about the discussion made me wonder whether you couldn't work around this by using a hostname to connect to the Emby Server?

I also don't know your setup, but in any case, there should be a way to make this going.

[bandit8623 213]

33 minutes ago, softworkz said:

I'm not familiar with the actual issue, but thinking about the discussion made me wonder whether you couldn't work around this by using a hostname to connect to the Emby Server?

I also don't know your setup, but in any case, there should be a way to make this going.

This seems like a router problem to me.  if some things load and others dont.  options like opnsense and pfsense have ways i bet that would take care of the problem.

[softworkz 5065]

12 minutes ago, bandit8623 said:

This seems like a router problem to me.  if some things load and others dont.  options like opnsense and pfsense have ways i bet that would take care of the problem.

No. See here:

On 12/15/2025 at 8:54 PM, ebr said:

As noted in those discussions, the error is in a 3rd party library the app uses for image processing so we can't "fix" it short of re-writing how the app handles images - something we simply cannot justify at this time.

An image library may have issues in dealing with urls having ipv6 IP addresses, but it surely won't have issues with host names as an image library is very unlikely to go so low-level that the IP address type would matter at the network level.

Edited December 18, 2025 by softworkz

[bandit8623 213]

21 minutes ago, softworkz said:

No. See here:

An image library may have issues in dealing with urls having ipv6 IP addresses, but it surely won't have issues with host names as an image library is very unlikely to go so low-level that the IP address type would matter at the network level.

it would seem hostnames would fix

[softworkz 5065]

18 minutes ago, CBers said:

You'll probably need to create one in the Android forum.

Ohhh hm, that ATV forum is full of topics about that ipv6 image problem...

 

[Cr8iveLosr 97]

@softworkz,

First, I want to say that I genuinely appreciate you stepping in and trying to understand this. You are widely regarded as the sharpest technical minds here, which is exactly why I took your comments seriously and why I wanted to respond carefully rather than let this drift into frustration or misunderstanding.

I do want to clarify intent up front. This was never meant to intentionally reopen an old issue or resurrect a sore spot. The IPv6 image problem was mentioned only to explain why, despite strongly preferring the Android TV app, I personally cannot use it. That was the entire purpose. It was context, not a request for help, and not an attempt to push for a fix.

Since you understandably approached this from a problem solving angle, it is probably useful to explain why this has already been explored very thoroughly from the user side and where the actual hard stop is.

From the user perspective, this setup has been pushed as far as it reasonably can be without modifying the client itself.

The Emby Server is accessed via a hostname or domain, not a raw IP address.
Public DNS is properly configured.
Valid SSL certificates are in place, converted to PFX, and used by Emby.
A reverse proxy using Nginx is correctly configured.
The internal network supports dual stack IPv4 and IPv6.
The issue only occurs for clients outside the LAN that receive a global IPv6 address from their ISP.
Server connectivity, playback, metadata, and API calls all work correctly.
Only artwork fails to load, and only in the Android TV app.

At that point, this is no longer a DNS, routing, SSL, or general networking problem.

To my knowledge, this issue was first documented publicly in 2020 in the following thread, and as you have since discovered, many similar reports and follow-up discussions have appeared over the years:

https://emby.media/community/index.php?/topic/92697-images-fail-to-load-if-emby-server-local-ip-address-setting-is-set-to-ipv6-address/

 

In that thread, the root cause was identified as the image loading pipeline used by the Android TV app, specifically Glide. This was not speculation. It was backed by logs and later tied directly to an upstream Glide bug:

https://github.com/bumptech/glide/issues/4369

That issue documents Glide failing to correctly handle IPv6 literals, particularly when ports are involved, even when accessed via hostnames. In other words, the failure occurs after DNS resolution, inside Glide’s URL parsing and request construction, not at the network layer.

This is why suggestions such as switching to hostnames, changing routers, reverse proxies, or IPv4 availability elsewhere do not resolve the issue. None of those change the fact that Glide ultimately encounters an IPv6 endpoint it cannot process.

A possible workaround was also discussed at the time and documented externally, for example here:
https://www.programmersought.com/article/59101040107/

However, that workaround requires application level changes such as custom Glide model loaders, URL rewriting or interception, or patching Glide internals. All of those require modifying the image pipeline in the client itself. This aligns with what has been stated more recently by Emby staff, namely that fixing this would require rewriting how the Android TV app handles images and that this is not justifiable for that app.

What is important to add, and why I am mentioning this now, is that this is not just a theoretical limitation. Another project actually took this path.

In 2023, Jellyfin’s Android TV client replaced Glide entirely with Coil, as documented here:
https://github.com/jellyfin/jellyfin-androidtv/pull/2889

That change removed Glide from the image pipeline and avoided the class of issues tied to its IPv6 handling. This demonstrates that the root problem is not an inherent Android TV limitation, but a consequence of the image library choice and the cost of modernizing that stack.

I am not raising this to argue that Emby should have done the same. I fully understand the resource, maintenance, and product direction tradeoffs involved. I am mentioning it only to underline that the limitation is architectural and already well understood, not something that can be solved with configuration changes or workarounds at the network level.

To bring this back to intent, I am not asking for this to be fixed. I am not trying to reopen an old bug. I am not tying this issue to the move toward the Universal app. I was only explaining why, for me, the Android TV app, which many of us agree offers the better TV experience, is not actually usable in practice.

I do appreciate you engaging in good faith and trying to help. In this case, the limitation is already acknowledged, architectural, and historical. At this point it serves only as context for why “just use the TV app” is not always a viable answer.

Thanks for taking the time to read and consider this.

[ebr 16169]

We have a possible solution to this now and we'll be looking at it in the next week or so.

[softworkz 5065]

@Cr8iveLosr - thanks for the message, no need to be defensive about intentions, of course everybody wants to get "their things" working.

After reading I've looked into the subject briefly, mainly because it doesn't make sense to me why an image library would even have such kinds of issues (networking),. That came clear quickly: it's more an "image caching library" than an "image library".

The bug appears to be well-known: the library was applying some cleaning on URLs by removing invalid characters (doesn't actually make much sense in the first place: when a URL is invalid, it might become formally valid after removing those chars, but this does in no way mean that it's automatically the right and intended URL).
As part of this "cleanup", it also removed square brackets - but these are only invalid in the path part while for v6 IPs it is even mandatory that the address must be enclosed in square brackets. Removing those as part of their cleanup made those URLs invalid - that's the bug (btw. they fixed it three months ago).

In a URL with DNS name, there are no square brackets to remove - that's why I suggested that. 

What you are alluding to, is not right, though. What is never happening is that you would be giving a URL with DNS name to a library (like https://my.com/img.png) and the library would then resolve the DNS name to an IP address in order to replace that in the URL (like https://[::1::2:3:4:5:6]/img.png) and that the bug would hit in  then. Such things are done at lower levels where nobody is talking URL. (also, you cannot drop a DNS because that may ne needed for the host-header protocol and most importantly for TLS validation.

If the connection to Emby server is made via host name and image loading is still failing, then  it can only mean

• either
  that the generated image URLs that are given to Glide are still not using the DNS name (but an ipv6 address in the URL instead)
  (reason would need to be investigated
   
• or
  it's an entirely different bug