FlixorUI Beta.1: Discussing Various Issues And Solutions

Hey everyone! Let's dive into a discussion about the initial Beta.1 version of FlixorUI. A big shoutout to the developers for their hard work on this first release! It's looking promising, and we're excited to explore its potential. In this article, we'll break down some of the issues encountered, share insights, and hopefully, find solutions together. Remember, it's a beta, so hiccups are expected, and our collective feedback is crucial for improvement. So, let’s roll up our sleeves and get into the nitty-gritty details!

Initial Impressions and Key Observations

The first version of FlixorUI has certainly made a splash, and there's a lot to be excited about. However, as with any beta release, there are a few kinks to iron out. One of the early users shared some detailed observations, and we're going to dissect these points to understand them better. This kind of feedback is gold because it helps developers prioritize what needs fixing and what areas need further attention. We're here to ensure FlixorUI becomes the best it can be, and your input is a massive part of that journey. Let's get into the specific issues that have been raised and explore them together.

FRONTEND_URL Configuration Issue

One of the significant issues reported revolves around the FRONTEND_URL variable. Users have found that setting this variable can lead to problems with accessing FlixorUI from a Wide Area Network (WAN). Specifically, with FRONTEND_URL configured, browsing from outside the Local Area Network (LAN) becomes problematic. Disabling this variable in the docker-compose file seems to resolve the issue, allowing access from both WAN and LAN. This workaround suggests a potential misconfiguration or bug related to how FlixorUI handles the FRONTEND_URL setting, especially concerning network accessibility. Furthermore, the OpenID Connect (OIDC) flow appears to be affected when FRONTEND_URL is set, resulting in a loop back to the sign-in page even after successful authentication. This behavior indicates a deeper issue with how FlixorUI manages authentication and session handling when a specific frontend URL is defined.

To address this, it's essential to delve into the code and configurations related to URL handling and OIDC integration. The development team should focus on identifying how the FRONTEND_URL variable influences the routing and authentication processes. Testing various network configurations and authentication scenarios will be crucial in pinpointing the exact cause of these issues. A systematic approach to debugging, including detailed logging and error tracking, will be invaluable in resolving these connectivity and authentication challenges. It's also crucial to ensure that the documentation accurately reflects the intended behavior and configuration steps for the FRONTEND_URL variable, preventing future confusion among users.

Plex URL Handling in Settings

Another notable issue is the backend's behavior concerning the Plex URL in the settings. Users have reported that the system is quite selective about the Plex URL it accepts. Specifically, it appears to have a preference for the plex.direct URL and tends to revert to it, even when a user attempts to input their Plex public URL. This behavior is problematic because users might have specific reasons for wanting to use their public URL, such as custom domain setups, reverse proxies, or other network configurations. Forcing the plex.direct URL can bypass these setups and create accessibility issues for users who rely on these configurations for remote access.

Investigating this issue requires a thorough examination of the backend's URL validation and handling logic. The development team needs to identify why the system is reverting to the plex.direct URL and whether this behavior is intentional or a bug. If it's intentional, the rationale behind this decision should be clearly documented, and there should be an option for users to override this behavior if necessary. If it's a bug, the team should focus on fixing the URL handling logic to correctly accept and persist the user's preferred Plex URL. User feedback has made it clear that this flexibility is crucial for accommodating various network setups and user preferences. Detailed logs and error messages related to URL validation could provide valuable insights into the root cause of this problem.

Web Player Settings and Exceptions

Moving on to the web player, users have encountered issues when modifying settings within the web player interface. Actions such as changing audio or subtitle tracks, or adjusting the quality, often trigger exceptions in the UI. This results in a less-than-smooth user experience, as these settings are essential for tailoring playback to individual preferences and network conditions. The silver lining, however, is that despite the UI exceptions, the requested settings do take effect upon page refresh. This suggests that while the underlying functionality is working, there's a glitch in how the UI handles these changes in real-time, leading to error messages or unexpected behavior.

To tackle this, developers should focus on the client-side code responsible for handling setting changes and UI updates. It's crucial to identify the specific events or functions that trigger these exceptions and understand why they're occurring. Debugging tools and browser consoles can be invaluable in tracing the flow of execution and pinpointing the exact point where errors are thrown. It's likely that the issue stems from asynchronous operations, incorrect data handling, or UI update mechanisms that are not properly synchronized with the backend. Addressing these issues will significantly improve the user experience by making setting changes seamless and error-free. Thorough testing across different browsers and devices is also essential to ensure consistent behavior and reliability.

Playback Resumption Issues

Another significant usability issue reported is the failure to resume playback correctly. Users have observed that playback consistently starts from the beginning (00:00), regardless of the previous playback position. This behavior is frustrating, especially for longer content like movies and TV shows, as users have to manually seek to their last watched point. The ability to resume playback is a standard expectation in modern media players, so this issue needs to be addressed to meet user expectations and provide a polished experience.

The root cause of this problem likely lies in the way FlixorUI handles playback state and stores resume points. The development team should investigate the code responsible for managing playback sessions and saving progress. Key areas to examine include how playback position is tracked, when and where it's stored, and how it's retrieved when resuming playback. Potential issues could involve incorrect storage formats, synchronization problems between the client and server, or bugs in the logic that calculates and sets the resume point. Debugging this issue will require careful analysis of the playback lifecycle and data flow, as well as thorough testing with various media formats and scenarios. Fixing this will greatly enhance the convenience and user satisfaction with FlixorUI.

Subtitle Handling: PGS Subtitle Display

Subtitle support is a critical feature for any media player, and FlixorUI's handling of Presentation Graphics Stream (PGS) subtitles has been flagged as an area needing attention. Users have noted that PGS subtitles are not being displayed or handled correctly. PGS subtitles are image-based, which makes them different from text-based subtitles and often requires specific rendering techniques. The user mentioned a GitHub repository focused on enabling PGS subtitle display using a canvas overlay on a web player, highlighting that there are existing solutions and approaches to tackle this challenge.

Addressing PGS subtitle support will likely involve integrating a rendering solution that can handle image-based subtitle formats. The development team may need to explore libraries or techniques for drawing PGS subtitles onto a canvas element or using other browser-supported methods. The mentioned GitHub repository could serve as a valuable resource for understanding implementation strategies and best practices. Correctly displaying PGS subtitles is essential for users who rely on this format for accessibility or language support. Thorough testing with different PGS subtitle files and playback scenarios will be necessary to ensure a robust and reliable implementation. Enhancing subtitle support will significantly broaden FlixorUI's appeal and usability.

Direct Play vs. Transcoding Discrepancies

A perplexing issue has been raised regarding the reporting of direct play versus transcoding status. Users have observed that Tautulli and Plex show direct playing even when a change in quality was requested from FlixorUI, which should have triggered transcoding. This discrepancy is concerning because it suggests a potential miscommunication between FlixorUI and the Plex Media Server regarding the actual playback method. The user also wondered how the "Limit remote stream bitrate" setting would be triggered to stay within WAN bandwidth, further emphasizing the importance of accurate transcoding management.

Investigating this issue requires a deep dive into how FlixorUI communicates with the Plex Media Server and how it signals transcoding requests. The development team needs to examine the API calls and data exchanges between the two systems to identify any inconsistencies or errors in the reporting mechanism. It's crucial to ensure that FlixorUI correctly informs Plex when a transcode is necessary and that Plex accurately reflects this status in its monitoring tools like Tautulli. The "Limit remote stream bitrate" functionality is also tied to this, as it relies on accurate transcoding information to enforce bandwidth limits. Debugging this will likely involve analyzing network traffic, API responses, and server logs to trace the flow of information and pinpoint where the discrepancy occurs. Accurate reporting of playback status is essential for users to understand how their media is being served and to optimize their streaming experience.

Web Player Incompatibility on iOS

Compatibility across different devices and platforms is paramount for any web-based media player, and a significant issue has been reported regarding the web player's functionality on iOS devices. Users have found that the web player is not working on iOS, with tests conducted on both Safari and Chrome browsers. This lack of compatibility severely limits the accessibility of FlixorUI for a large segment of users, as iOS devices are widely used for media consumption.

Addressing this issue will require a focused effort on ensuring cross-browser and cross-platform compatibility. The development team needs to investigate the underlying causes of the incompatibility on iOS, which could range from browser-specific quirks to issues with media format support or JavaScript execution. Debugging on iOS devices, using remote debugging tools if necessary, will be essential for identifying the root causes. It's also important to consult web development best practices for iOS and ensure that the web player adheres to these standards. Testing on a range of iOS devices and versions will help to ensure a consistent and reliable experience for all users. Fixing this incompatibility will significantly enhance the reach and usability of FlixorUI.

Conclusion: A Promising Start with Room for Growth

So, there you have it, guys! A comprehensive look at the initial issues spotted in the Beta.1 version of FlixorUI. While there are definitely some wrinkles to iron out, the overall sentiment is super positive. This first version shows a ton of promise, and it's exciting to see such a solid foundation to build upon. Remember, betas are all about finding these little hiccups and working together to squash them. Your feedback is invaluable in this process, so keep those observations coming!

The issues we've discussed, from FRONTEND_URL glitches to playback resumption and iOS compatibility, are crucial for the development team to tackle. Each solved problem brings FlixorUI closer to becoming a top-notch media streaming solution. It’s a collaborative effort, and the developers are clearly listening and working hard to refine the platform. The fact that many of these issues seem minor relative to the work already accomplished speaks volumes about the quality of the initial release.

We're all eager to see the next updates and improvements. The potential for FlixorUI is immense, and with each iteration, it's becoming clearer that this could be a game-changer for media streaming. Thanks to everyone who’s testing, providing feedback, and contributing to this project. Let's continue the discussion, share our findings, and help make FlixorUI the best it can be. Stay tuned for more updates, and keep those comments and suggestions rolling in. Together, we can help shape the future of FlixorUI! High five to the developers and the community—let's keep the momentum going!