[jonwise80]

icon.png
Excited to announce the General Availability of MeTube!

Release History:
- 1.0.0: General Availability, tested on Touchpad only
- 1.0.1: Security overhaul, to keep the big G happy with me. Required update for 1.0.0 users.
- 1.0.2: Basic support and testing done for webOS 2.x phones, improved search bar.
- 1.0.3: Configurable preferences, including API keys, layout fixes for Pre3.
- 1.0.4: Advanced features for self-hosters, Beta support for webOS 1.x, layout improvements for tiny screens
- 1.1.0: Support for all webOS devices -- including Pre and Pixi Plus, bug-fixes for self-hosters, new playback strategy options.

LuneTube has been dead for months now, the original dev hasn't had time to update the version of youtube-dl he built for webOS -- a situation that is unlikely to improve as the cat-and-mouse game between Google and youtube-dl continues. MeTube is not dependent on compiling modern code for an abandoned platform, instead it uses a web service that acts on behalf of webOS to fetch the YouTube videos you want to watch. That web service can use the latest youtube-dl without compilation issues. The web service is heavily derived from work by Alex Shnitman (alexta69 on Github) with some supporting Apache2/PHP functions I whipped up (eventually I hope to migrate these into my MeTube fork.)

The mental model for MeTube is a little different than you might be used to. The thing to keep in mind is that you're never directly interacting with YouTube from your device -- you are submitting requests to the MeTube web service to interact with YouTube for you. That verb "submit" is the driving force of the UI:

• You can submit a "search" request, by entering any search word or phrase that doesn't contain "youtube.com" and the server will search on your behalf.
• You can submit a "fetch" request, by entering a YouTube video link (a fully formed one that contains "youtube.com" -- not a shortened URL).
• Once done, the app will submit a "list" request, to see if your video is ready on the server repeatedly (until a timeout)
• Finally the app will submit a service request to the built-in webOS video player, asking it to open the URL to the fetched video on the server

All this happens pretty smoothly in most cases. You'll note the transition from "search" to "fetch" involves you selecting a search result from a list, which updates the search box with the URL, so you can then submit again.

There are a bunch of caveats to be aware of -- some of which I can improve on the server side, as I have time, but some will likely always exist, because of the server-side model:

• Long videos just aren't going to work: the server is racing to fetch and convert the video for you before the time-out. If it can't get it done in time, the whole request is just abandoned. Practically, this means the maximum supported video length is usually under 30 minutes -- give-or-take.
• You might think "why not just increase the time out?" Well, there's another race interaction that exists, where files have to be "new" to be discovered by the client. That means the server has to be pretty judicious about cleaning up after itself. If the [clean-up interval] overlaps with the [client time-out + time it takes to stream the video], then the video will get nuked before you're done watching it.

I think I've found the right combination of timings for a pretty reasonable experience, but may continue to tweak over time. Fortunately, my new Updater Service is built-in, so if there's an update to the app, you'll know about it as soon as it gets published to the Museum!

MeTube does not require a proxy (although it is compatible with them), and is a tiny install on your device. All code is open source, and available on GitHub. I've done all the development on the Touchpad, but I will go back and tune it for phones shortly -- it works on a Veer, so should work on a Pre2 and up, but the screen layout needs to be optimized for tinier screens.

screenshot1.png

MeTube is available in App Museum II now, or by direct download from the online Museum catalog!

[jonwise80]

MeTube 1.0.2 with basic support for webOS 2.x phones is out. This version also improves the search bar -- both visually and functionally. Short YouTube links are supported (eg: youtu.be) and an issue with certain special characters work now, but there remains a known issue with any YouTube video that has an emoji in the title -- both webOS and the server garble them, rendering the video unplayable.

[gazaud]

Good job! Thanks a lot for keeping maintain the flame.

[jonwise80]

MeTube 1.0.3 is out now!
This is a significant feature and bug fix update that, barring any issues, finishes off everything I hoped to do on the client side:

• Encoding of special characters is now supported across the board. While webOS still can't render emoji's, their presence in a YouTube title will no longer prevent playback.
• All SDK 2222 and up devices are now "first class" citizens: Pre2, Veer, Pre3 and TouchPad all "just work." Some weird gymnastics had to be done to handle long strings in a list -- its not perfect, but it works.
• Added support for inputting your own Google API key. Yesterday I used up my search quota doing testing -- to avoid having this happen to you, just visit Google's developer console and create your own key!
• Also added the concept of MeTube client key, which may some day unlock additional server-side features.
• Added a few other configurable preferences for controlling the search and video prep experience -- which, you can tweak depending on how patient you are.

I don't have all the devices to test with, so I had to use the emulator. I'd appreciate feedback -- especially on the Pre3. If you find a video that doesn't play, please send it to me. Similarly, screenshots of layout issues help the most.

Grab this update from App Museum II!

[gazaud]

Encoding fails with the new 1.0.3 version on TP and Pre 3. Timeout on all videos (short videos) wether convert time preferences are set on 30 seconds or 3 minutes. Thanks.

[jonwise80]

Thanks for testing! I see the problem, but don't know how to prevent it from happening again.
Someone tried watching a 24/7 Live stream (they must be a QA tester at heart, because I didn't even think to try that!) which resulted in the server continuously encoding the video -- blocking all subsequent video requests.

At search time, Google only gives back minimal metadata about each video. The fact that a video is live doesn't seem to be in there -- they don't even include the length of the video. They basically give the title, the ID to form a video link, and some poster frame URIs. To get the rest of the information would require a follow-up request on each video in the result set (a common problem with REST that GraphQL seeks to deal with.)

I have cleared the Live stream from the server's work queue, and the remaining 10 items in the queue processed quickly. The app should be working again. I'll think about how to mitigate this scenario, but in the meantime, help out your fellow webOS users and don't try to watch Live streams

Update: OK, I found it -- you can't request an exclusion of Live videos from the search results, but you can remove them from the search results based on the response member liveBroadcastContent. I just need to decide if this is a server-side filter (gnarlier code), or a client-side change (requires an app update)...

[jonwise80]

MeTube 1.0.4 - Massive Update

In the process of pushing version 1.0.4 to the App Museum. This version has a slew of changes -- some of which are in Beta: I'm looking for testers.

First up, this release allows you to configure the service URL base. This enables you to host the MeTube service yourself -- so you don't have to share my little server's bandwidth and processing time with other users. If you value performance and privacy you might consider this option -- service improvements and docs coming soon.

Second, this version includes a new playback strategy that supports webOS 1.x devices. I tested it with an original Pre, and it works! It takes longer to prepare the video on the device, but its a reasonable trade off. Beta users can try this feature with a special client key -- PM me if you want to try it. You can also try this playback strategy on other devices with the beta key as well. I'm interested to see if this approach is less "crashy" on the Touchpad (which seems to do a forced Luna start when the built-in video player feels stressed or neglected.)

Finally, I made some minor improvements to the UI that should reduce some race conditions and many (not all) random Mojo text-wrapping behavior.

If the beta period goes well, we'll have a YouTube solution for the entire legacy webOS line up, that can last as long as there is someone out there able to host the service (runs fine on a Raspberry Pi 3b+)

[jonwise80]

MeTube is ready for Self-Hosting!

Everything you ever wanted to know about running your own MeTube service is here:
https://github.com/codepoet80/metube-php-servicewrapper

A little more background:

The MeTube app is mostly a client for a PHP service wrapper I wrote that, in turn, uses an open source project called MeTube, which is a web UI for youtube-dl. Is that confusing enough for ya?
Originally, the Open Source project didn't include a quality setting that would work for webOS, so I forked it and hacked one in.
It also didn't include a way to get access to the resulting converted file -- it is literally just a GUI so you didn't have to use the youtube-dl command line. That's where the service wrapper comes in. It wraps all the functions of MeTube with alternate end-points, on which I could add some obfuscation (to try to keep the Big G happy), and additional functionality -- like actually listing and playing the files.

All of this is remarkably thin, and 100% up-to-date. The service wrapper used a recent version of MeTube, which is actively maintained, and uses the latest version of youtube-dl, all of which runs on any modern Linux, etc... Its the perfect stack to "help out" our little webOS clients.

There are a couple weak links in long-term sustainability for webOS, though:
- As long as I can afford to host the service in Azure, it can be available to everyone -- that's what the app is counting on right now. If I go broke, or have to move, etc... the service goes away.
- As long as I could maintain a fork of MeTube, the service could continue to use the latest youtube-dl, and stay ahead of constant efforts to shut that down. If I stop being able to keep up with any of the downstream projects, it dies. (this is the cat-and-mouse game that killed LuneTube)

With a self-hosted version, and recent changes to the app, both problems are solved:
- I worked with the MeTube developer on a pull request to get "custom" quality settings into the Main code -- I no longer need to maintain a fork, we're all just using his latest.
- With the lightweight service wrapper, and something as small as a NUC, you can run the service on your own box. Just update the Preferences in the app to point to your server and configuration, instead of mine.

All the details of how to do this are here:
https://github.com/codepoet80/metube...main/README.md

Nomad84 and I chatted for a bit on the webOS IRC and he's going to try it out, and we can improve the docs as we go.

This pattern works for devices as old as the original Pre because they perform the function of a Proxy -- without needing an actual Proxy (which webOS 1.x doesn't support) and can be use to restore functionality to virtually any web service. Of note, my skills are going to limit me to web services that don't require authentication... I can't wrap my head around how I'd do OAuth2 on webOS, so that does limit the universe somewhat!... but that's just my limitation -- go hit GitHub and find an open source project for whatever you've been dying to get onto your Touchpad or Pre. If you've been thinking of trying your hand at webOS development, there's never been a better time!

I have a few more tweaks coming to the client app, based on feedback from mrhall17, and then I'm wrapping this one up. My long delayed fitness app (and fitness in general) are next...

[jonwise80]

MeTube 1.1.0 - Feature Complete

With thanks to my two beta testers (who now make an appearance in the About dialog!), version 1.1.0 has been pushed to App Museum II.

This version addresses multiple issues found during testing of self-hosting scenarios, finalizes support for webOS 1.x, including the original Pre and Pixi Plus, and introduces a new playback strategy for webOS 2+ users. You can toggle the strategy in Preferences, and if you use the download first approach, I came up with a way to show progress, so it doesn't feel like your device is hanging.

Service-level filters have been added to remove "Live" video streams, which aren't compatible with the service, and also to set the Safe Search level to "moderate" -- if you want explicit content, there's probably better ways to find that, but feel free to self-host and modify to your whims. Nomad84 is working on some docs for dockerizing the service wrapper, if that's your preferred deployment approach.

This completes all the features I'd hoped to deliver in this app -- it works on pretty much everything reasonably possible, and I've successfully watched videos up to an hour in length. The Touchpad video player crashes Luna afterward -- but there's nothing I can do about that. You will likely even experience crashes on short videos... unfortunately the bug is in HP's code, not mine. Try changing the playback strategy if it bothers you. This app will be maintained going forward, but no more major features are planned - and most maintenance will likely be on the server side, as youtube-dl or the MeTube container are revised. If you have ideas for the front end, please do pull the repo and start coding!