1 From Media Server to Film and Television Showcase Site

For people who have collected a large number of movie and TV resources at home, they probably have more or less the idea of showing their collected resources to everyone to take a look—of course, “taking a look” here simply means looking at the posters, looking at the scale of the collection, and looking at what movies have been collected, rather than actually providing online playback services. After all, playback will not only continuously occupy the limited upstream bandwidth of home broadband (currently, domestic operators have very strict restrictions on upstream traffic of home broadband, and slightly larger traffic may trigger speed limits or even bans); at the same time, publicly providing playback services for movie and TV resources is itself a relatively sensitive topic, and is not suitable for long-term operation as a personal hobby project.

Therefore, most of the time, for collectors like me, the requirement is actually very simple:Turn one's own film and television collection into a publicly accessible showcase site. Allow others to see what movies and TV shows you have collected, as well as the general scale of the entire collection system, just like browsing a Douban movie list.

From a technical perspective, achieving this goal does not seem difficult. Currently popular media management systems, such as Emby, Jellyfin, and Plex, inherently provide mature Web interfaces that can automatically scrape posters, actor information, plot summaries, and various media metadata. On the surface, it seems the problem is solved simply by publishing one of these systems to the public network.

But after actual operation, you will find that things are not that simple. Although these systems all provide Web interfaces, their design goal is essentially still to provide media management and playback services for internal home users. In other words, they are first and foremost “media servers,” and only secondarily “web applications.”

And when we attempt to turn them directly into a film and television showcase site for internet visitors, various kinds of “misfits” will arise.

For example:

• Visitors just want to browse posters, yet they still need to go through a complete login process;
• Resource loading delays, which are barely noticeable in a local area network environment, are significantly amplified in a public network environment. Especially when there are many poster images and front-end static resources, the overall access experience will drop noticeably.
• The first load of the login page often has a noticeable delay, which is especially obvious during public network access. For ordinary visitors, a wait of over ten seconds can easily make them mistakenly believe the website is down;

The reason for this is not that these systems are poorly designed, but that from their inception, they were primarily meant to serve home media management scenarios. When the usage scenario changes from “internal home use” to “public network visitor browsing,” some originally inconspicuous issues are quickly amplified.

In other words, for a film and television showcase site, being accessible via the public network and being suitable for public network access are actually two completely different things. If you want to turn an off-the-shelf media management system into a film and television showcase site that is truly suitable for public network access, merely completing the public network publishing is far from enough. Targeted adjustments and optimizations around access methods, authentication processes, and user experience are also required.

This article will take Emby as an example to document how I solved these problems step by step and ultimately transformed it into a film and television showcase site suitable for public network access.

2 Prerequisites: Publishing Emby Using Cloudflare Tunnel

Before solving issues like login experience and access experience, a most fundamental problem must first be resolved:How to make the Emby at home accessible by the internet. For the vast majority of home audio-visual enthusiasts, Emby is usually deployed inside the home network, running on a NAS, mini PC, or home server. At this time, all access requests come from the local area network, so it can run stably.

But once you hope to transform it into a public network-accessible film and television showcase site, you must first solve one problem: how to allow internet users to access the Emby service at home.

The most direct solution is naturally a public IP combined with port mapping. If the home broadband has a public IP address (whether IPv4 or IPv6), theoretically, you only need to configure the corresponding port forwarding rules on the router to publish the Emby in the intranet to the public network. This solution was very common in the early days of personal website building and home server scenarios, with simple and direct configuration and almost no extra cost. But today, it has gradually become unsuitable as the default choice under a home environment.

First, we face the acquisition and long-term availability of a public IP. As IPv4 address resources become increasingly scarce, more and more ISPs are starting to adopt CGNAT (Carrier-Grade NAT) solutions, and many home broadbands actually no longer possess a true public IPv4 address. Even if a public IPv4 can currently be applied for, it may not be stably retained in the long term. Although IPv6 fundamentally solves the address exhaustion problem, it still has certain limitations for websites open to the public. This is because visitors must also have a usable IPv6 network environment to access the site normally. This means whether the website can be successfully accessed depends not only on the server side but is also affected by the visitor's network conditions, thereby raising the overall access barrier.

Secondly, even if the public IP issue can be resolved, directly exposing the home network to the internet will still bring additional operation and maintenance costs. For example, port opening and routing configurations need to be maintained by oneself, the service needs to face scans and probes from the public network in the long term, HTTPS certificates need to be applied for and managed separately, and the real public IP will also be directly exposed to the external network. For a film and television showcase site that mainly serves a display function, these extra investments seem somewhat not worth the candle.

In addition, there is another often overlooked but very realistic factor: in recent years, domestic ISPs have generally become more cautious about running Web services on home broadband. Although specific policies vary across different regions and ISPs, providing website services to the outside world through home broadband in the long term inherently carries a certain degree of uncertainty. For a film and television showcase site that hopes to run stably in the long term, this is clearly not an ideal basic condition.

For the above reasons, for individuals building a film and television showcase site open to the public, we prefer a publishing method that neither relies on a public IPv4 nor is affected by the popularity of IPv6. Against this background, I ultimately chose another solution more suitable for home scenarios:Cloudflare Tunnel. Its key difference does not lie in “having an extra layer of proxy,” but in the change of the access model—it no longer relies on inbound ports; instead, the home server actively establishes a continuous connection channel outward, and Cloudflare is responsible for forwarding external access requests.

For a brief configuration of Cloudflare Tunnel, you can refer to the article:Use Tunnel technology to allow home broadband without a public IP to leverage Cloudflare for free to achieve fast website building (Recommended), and friends who want to learn more can refer to the article:Cloudflare Tutorial (9) Introduction to Common Zero Trust Features and Multi-Scenario Usage Tutorial。

For a home environment, the biggest change brought by this method is: public network access capability no longer depends on whether there is a public IP. In other words, as long as the home server can access the internet normally, it can stably provide services to the outside. At the same time, issues like port exposure and public network scanning also disappear, and the home network no longer needs to specially adjust routing and open ports for public network access. For a film and television site mainly focused on showcase, this means the deployment and maintenance of the entire system are much simpler.

In addition, Cloudflare Tunnel also solves the application and renewal of HTTPS certificates along the way. And since all access traffic passes through the Cloudflare network, subsequent cache optimization, access acceleration, or some modifications to the access process also have a foundation for implementation.

Therefore, in this project, the role of Cloudflare Tunnel is not just as simple as publishing Emby to the public network. It actually serves as the unified entry point for the entire film and television showcase site, and many subsequent optimizations at the experience level are also completed on top of this layer.

After completing the public network access, the real problems then begin to emerge:How to turn a media system designed by default for logged-in users into a film and television showcase site suitable for “browsing only, no operation.”

3 Public Network Access Experience Optimization

1 Creating a New Independent Showcase Instance (Optional but Recommended)

When using Emby as a public network film and television showcase site, an easily overlooked but actually critical question is: whether one should directly use the existing production media library to provide external access.

From an implementation perspective, this is of course the simplest solution, as directly utilizing the existing media server can quickly provide a usable showcase entry point. However, from a system architecture perspective, this approach essentially runs the “daily use environment” and the “public network showcase environment” within the same instance. Although both use the same media library, their goals are completely different: one is oriented towards personal management and playback, while the other is oriented towards public browsing and showcase.

This coupling usually does not cause obvious problems in the short term, but under long-term exposure to the public network, it will gradually introduce some hidden risks. For example, any configuration adjustment may affect the showcase effect, daily maintenance operations may also interfere with external access, and the showcase site itself cannot evolve independently in a stable and controllable environment.

Therefore, in a more secure practice, a clearer approach is to separately deploy an Emby instance for showcase (usually recommended to be deployed via Docker), logically or physically separating it from the daily-use media server. This showcase instance can share media files or only synchronize a portion of the media content. Its core purpose is not to expand functionality, but to draw a clear boundary between “daily use” and “public showcase”.

If your personal collection of film and television resources is too large, manually creating all media libraries and rescanning them after building a new showcase instance will waste a lot of time (scanning just one ”European and American Movies” library, including scraping time, takes at least 1-2 days). In fact, there are tricks to quickly migrate media library data. For details, please refer to the article:Emby Series Advanced: Quickly Migrate Media Library Data Between Old and New Emby Servers。

Meanwhile, from a security perspective, since this showcase instance needs to be exposed to the public network environment, using default or weak administrator account and password combinations should be avoided as much as possible to reduce the risk of scanning or credential stuffing attacks.

However, it should be noted that this step is not mandatory. This section is more accurately positioned as a recommended architectural isolation strategy rather than a prerequisite.

Only after completing this layer of choice do we enter the real issue of optimizing the access experience, which is how to allow visitors to enter the system itself with the lowest cost.

2 Guest Account: Lowering the Access Barrier

When using Emby as a public network movie showcase site, the first problem to solve is actually not performance, but the access barrier itself: by default, Emby's access model is still designed around “user login,” and any access must first complete account authentication (entering username/password) before entering the media library page.

However, in the usage scenario of a movie showcase site, the behavior of most visitors is very clear: browsing film and television resource posters after opening the link, rather than entering a complete media system. Therefore, if the complete login process is still retained, it essentially causes the act of “viewing content” to be interrupted by unnecessary steps.

To solve this problem, the method I adopted is to create an account: ”Guest/empty password” and use it as the default access entry point (only displaying the Guest account and hiding other accounts, including the administrator account):

The permissions of the Guest account itself are also strictly limited, with only read-only browsing capabilities enabled, excluding playback and management permissions, ensuring it is only used as a showcase portal. It must be emphasized that using Guest here does not “cancel the login step”, but merely simplifies the authentication process to the extreme: after users enter the site, they only need to click the Guest login portal once to directly enter the poster browsing interface, without entering a username and password, and without any additional operations.

To display only the Guest account on the login interface, you need to configure hide settings in other accounts:

After the adjustment, the access path changed from the original: manually enter ”username/password” to log in → enter the system → browse content, to: click Guest login → enter the poster wall → browse content. Although an authentication step still essentially exists, for visitors, this step has transformed from a “login process requiring understanding and inputting information” into a lightweight operation of “click once to enter”. In actual experience, this difference is crucial because it directly determines whether visitors will bounce at the very first step.

Therefore, from the perspective of the entire system transformation, the Guest account is not a functional optimization, but the first step in converting Emby from a “user-oriented media system” to a “browsing-oriented showcase system”.

3 Cloudflare Caching: Optimizing Resource Loading

After lowering the access barrier through the Guest account, visitors can already enter Emby relatively smoothly.

However, new problems will soon arise. For Emby deployed in a home network, every public network access actually needs to cross the internet to reach the home server and then return the results. Although the latency of a single request may not be very high, the Emby Web page itself loads a large amount of resources, including frontend static files, poster images, and various metadata APIs.

In a local area network environment, these requests have almost imperceptible latency; but when placed in a public network environment, a large number of requests stack up, and the page response speed drops significantly.

Since the entire system has already connected to Cloudflare via Cloudflare Tunnel, the most natural optimization method is to utilize Cloudflare's edge caching capabilities to cache content with lower change frequencies onto Cloudflare nodes as much as possible, rather than fetching from the home origin server every time.

In the actual configuration, I mainly use Cloudflare's Cache Rules feature (friends who are unfamiliar with CF cache rule configuration can refer to the previous article:Cloudflare Tutorial (6) CF Cache Rules Feature Introduction and Detailed Configuration Tutorial), and designed a cache rule tailored to the access characteristics of Emby (taking the domain of my showcase site ”movie.tangwudi.com” as an example):

(http.host eq "movie.tangwudi.com" and http.request.uri.path contains "/Images/")
or
(http.host eq "movie.tangwudi.com" and starts_with(http.request.uri.path, "/web/"))
or
(http.host eq "movie.tangwudi.com" and http.request.uri.path contains "/emby/Users/")
or
(http.host eq "movie.tangwudi.com" and http.request.uri.path contains "/emby/Items")
or
(http.host eq "movie.tangwudi.com" and http.request.uri.path contains "/emby/System/")

For requests that meet the above conditions, directly enable Cloudflare Cache and set the edge cache TTL to 1 month (up to 1 year maximum).

The reason for choosing these paths is mainly because the change frequency of their corresponding content is relatively low. Among them:

• /Images/ Mainly contains image resources such as movie posters, background images, and actor avatars;
• /web/ Corresponds to the static files of the Emby Web frontend, including JavaScript, CSS, and font files;
• /emby/Users/ Contains user-related information, which changes very little in showcase scenarios;
• /emby/Items Mainly provides media library metadata, such as movie titles, overviews, ratings, and other information;
• /emby/System/ Contains system configuration and basic status information.

For a movie and TV site that is mainly for showcase, the above content often does not change significantly for a long time, making it highly suitable for Cloudflare caching. After doing this, many requests can be responded to directly at Cloudflare edge nodes without needing to fetch from the home origin server.

From the user's perspective, the most direct change is faster poster loading and smoother page transitions; from the server's perspective, it reduces the extra pressure caused by a large number of duplicate requests on the home network and the Emby instance.

Of course, it should be noted that caching is not suitable for all APIs. For data involving real-time status, permission checks, or frequent changes, it should still fetch from the origin server, otherwise it may cause the displayed content to be inconsistent with the actual status.

However, for scenarios like movie and TV showcase sites that are mainly for browsing, simply caching the above paths can already yield a relatively obvious experience improvement.

4 Worker Landing Page: Refactoring the Waiting Experience (Optional but Recommended)

In fact, after steps 3.1 to 3.3, the movie and TV resource showcase site can already run normally. However, for domestic users, there is still an issue that significantly affects the experience: the homepage opens slowly.

This is not an issue with Emby itself, but rather the result of the entire access path working together: the user's request needs to pass through the Cloudflare network first, then be forwarded to the home server via Tunnel, while Emby Web still needs to load frontend resources, initialize the page, and request various media library data when opened for the first time.

Even after cache optimization, this process still cannot be completely eliminated. Especially in domestic network environments, it is not uncommon to wait for several seconds or even around ten seconds during the first visit.

From a technical perspective, this kind of problem is not easy to solve. Because it is not that a single API is slow, but rather the result of the entire access path and system initialization process stacking up. Continuing to invest a lot of energy into optimization often yields limited returns.

So I changed my approach: since the waiting cannot be completely eliminated, can we make the waiting more acceptable? In fact, when facing unavoidable loading processes, many large websites and applications do not simply shorten the time, but instead provide feedback on the current status to users in various ways, letting them know that the system is working normally: for example, installation programs display progress bars, games display loading screens when starting, and streaming media has fixed startup intros when loading, such as the familiar ”ta-dum” intro of Netflix movies:

Therefore, I added an extra Cloudflare Worker in front of Emby as a startup page (friends who are unfamiliar with the CF worker feature can refer to my previous article:Cloudflare Tutorial (7) Introduction to CF Worker Features and Practical Operation, Verification, and Related Technical Principle Research on Implementing ”Poor Man's APO for WordPress” Based on Worker to Accelerate Website Access), and changed the original entry that directly accessed Emby to a new access address: ”movie.tangwudi.com/start” .

When users visit this address, they will not enter Emby immediately, but will first see a simple startup page. The page will simulate the process of a movie and TV database starting up, for example:

连接影视资料库...
建立安全连接...
验证媒体服务...
准备访问入口...
正在进入影视库...

At the same time, combined with a progress bar and dynamic animation effects, users can perceive that the system is working. After a few seconds, the Worker will automatically redirect to the actual Emby login page. It should be noted that this method does not make Emby faster; from a technical perspective, it optimizes almost no performance metrics. But from the perspective of user experience, the feelings of the two are completely different.

The original situation was:

点击链接
    ↓
有emby图标的页面漫长的等待
    ↓
怀疑网站是否失效
    ↓
出现登录界面
    ↓
进入 Emby

And now, the situation is:

点击链接
    ↓
看到启动页面
    ↓
知道系统正在加载
    ↓
出现登录界面
    ↓
进入 Emby

The waiting time may not have changed significantly, but the users' acceptance of the wait has improved a lot. This is also the most interesting part of this optimization solution: it does not attempt to solve a difficult performance problem, but rather improves the user's perception of the entire system by redesigning the waiting process.

Of course, this step is not mandatory. Even without adding the Worker startup page, the optimizations completed previously are already sufficient to support a normally functioning media showcase site.

But if your primary visitors are also domestic users and you care about the experience of the first visit, adding such a lightweight startup layer can often bring more noticeable improvements than continuing to tweak performance parameters.

I will also post the Worker's JS code here for interested friends to refer to:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname !== "/start") {
      return fetch(request);
    }

    return new Response(`<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>正在连接影视资料库</title>

<style>
html,body{
    margin:0;
    width:100%;
    height:100%;
    background:#050505;
    color:#ffffff;
    overflow:hidden;
    font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",sans-serif;
}

.container{
    height:100%;
    display:flex;
    flex-direction:column;
    justify-content:center;
    align-items:center;
    text-align:center;
}

.logo{
    font-size:40px;
    letter-spacing:6px;
    margin-bottom:40px;
    opacity:.95;
}

.status{
    font-size:16px;
    opacity:.85;
    margin-bottom:22px;
    min-height:24px;
}

.progress-wrap{
    width:320px;
    max-width:80vw;
}

.progress{
    height:8px;
    border-radius:999px;
    background:#1f1f1f;
    overflow:hidden;
}

.bar{
    width:0%;
    height:100%;
    background:#ffffff;
    transition:width .5s ease;
}

.percent{
    margin-top:12px;
    font-size:13px;
    opacity:.65;
}

.footer{
    position:absolute;
    bottom:40px;
    font-size:12px;
    opacity:.3;
    letter-spacing:2px;
}

.fadeout{
    animation:fadeout .8s forwards;
}

@keyframes fadeout{
    from{opacity:1;}
    to{opacity:0;}
}
</style>
</head>

<body>

<div class="container">
    <div class="logo">MOVIE LIBRARY</div>

    <div class="status" id="status">
        正在连接影视资料库...
    </div>

    <div class="progress-wrap">
        <div class="progress">
            <div class="bar" id="bar"></div>
        </div>
        <div class="percent" id="percent">0%</div>
    </div>
</div>

<div class="footer">
    TANGWUDI MOVIE COLLECTION
</div>

<script>
const statusEl = document.getElementById("status");
const bar = document.getElementById("bar");
const percent = document.getElementById("percent");

const steps = [
    { text: "连接影视资料库...", progress: 18 },
    { text: "建立安全连接...", progress: 38 },
    { text: "验证媒体服务...", progress: 62 },
    { text: "准备访问入口...", progress: 85 },
    { text: "正在进入影视库...", progress: 100 }
];

const totalTime = 6000 + Math.random() * 2000;

let index = 0;

function nextStep() {
    if (index >= steps.length) {
        document.body.classList.add("fadeout");

        setTimeout(() => {
            location.href =
                "/web/index.html#!/startup/login.html?serverId=d2f780f97e4d4f39928b1b1f97d3ca7f";
        }, 800);

        return;
    }

    const step = steps[index];

    statusEl.textContent = step.text;
    bar.style.width = step.progress + "%";
    percent.textContent = step.progress + "%";

    index++;

    setTimeout(nextStep, totalTime / steps.length);
}

nextStep();
</script>

</body>
</html>`, {
      headers: {
        "content-type": "text/html;charset=UTF-8",
        "cache-control": "no-store"
      }
    });
  }
};

You can directly visit the following link to experience the final effect: ”https://movie.tangwudi.com/start”

Note: I basically update this showcase site once a year, and only update these 3 categories: ”European and American Movies”, ”Asian Movies”, and ”European and American Nostalgic Movies”. I'm too lazy to update the others, it's too much of a waste of time.

4 Afterword

Although after the previous modifications, an Emby-based movie and TV resource showcase site has already basically taken shape, and whether in terms of public network publishing, access barriers, or loading experience, it has already been able to meet daily display needs. However, from the perspective of long-term evolution, I do not think this will be the final solution.

The reason is actually very simple: Emby is, after all, a media server. Even though many problems have been solved through Guest accounts, Cloudflare caching, and Worker landing pages, in essence, it is still about adapting a system originally designed for media management. In other words, all the previous optimizations were actually doing the same thing: making Emby as suitable as possible to be used as a movie and TV showcase site.

But from another perspective, a website truly designed for showcase actually shouldn't involve Emby at all. For a showcase site, what we really need is nothing more than metadata such as movie titles, release years, ratings, introductions, actor information, poster images, and category tags. And these contents themselves already exist in Emby's database. In theory, as long as this data can be exported through APIs, and then combined with resources like poster images, we already have all the basic conditions required to build an independent showcase site.

Therefore, a more ideal architecture might be: Emby is only responsible for managing the media library and maintaining metadata, while the website itself is completely static. The website no longer relies on Emby when running, nor does it need to back-to-source to the home server through Tunnel. All pages, data, and image resources are directly deployed to a static hosting platform and distributed by CDN. This will not only make the access speed faster, but the overall architecture will also be much simpler.

In fact, in the process of tinkering with this showcase site, I have already begun to consider this direction and spent a lot of time looking for ready-made solutions on the Internet. But unfortunately, whether in the Emby, Jellyfin, or Plex communities, I have found almost no mature static showcase projects. Most discussions still focus on the media server itself, rather than how to export the entire media library into an independently running static website. This also means that if I really want to continue in this direction, there is a high probability that I will have to build it from scratch myself in the end.

However, once I actually started analyzing it, I realized that this matter is not as simple as initially imagined. Taking my current collection scale of 20,000 movies as an example, just generating index files containing movie information requires serious consideration of data structure design. How to synchronize poster images, how to organize resources, how to incrementally update data, how to implement search functions, and how the browser can efficiently render tens of thousands of records—all of these need to be designed separately.

Especially at the front-end display level, if you want to achieve a browsing experience similar to Netflix or Emby's poster wall, you must consider technologies like virtual scrolling; otherwise, the browser can easily experience performance issues due to rendering too much content at once. Similarly, the search function cannot simply rely on back-end interfaces, because static sites do not have database query capabilities in the traditional sense, which means a local index needs to be built on the browser side to complete searches directly via JavaScript.

These problems individually look not particularly complex, but when combined, they are actually already close to the scale of a small project. I even feel like I'm being forced to learn front-end frameworks ~~~. Therefore, this matter is still in the planning stage for now and has not officially begun implementation.

However, looking at it now, the solution introduced in this article is already enough to meet the needs of average friends for movie and TV resource display, while the static showcase site is more like a pit that I plan to slowly fill in the next stage. If this system is really completed in the future, then Emby's role in the entire architecture might change—it will no longer be the website itself, but just the data source behind the website.

As for when this pit can be filled, I can't say for sure right now. However, for personal projects, many times you don't need to have the final form right from the start. Letting it run first, letting it solve the immediate problems first, and then continuously adjusting and evolving it during actual use is often a more realistic path.

At least before the static solution actually lands, the solution introduced in this article is already enough for me to showcase my movie and TV collection to more people.