In September 2026 I'm going back to 2008 with... eMule?

But where can I watch Keroro again?

Surely there must be a site streaming it in French, so I can rewatch this series I remember so fondly? Nope, nobody. No streaming site, no DVD or Blu-ray reseller carries the French version of Keroro. Almost nobody talks about it online, apart from a reddit post or two as puzzled as I was.

I even started doubting my own memories, and if it weren’t for that theme song that’s still burned into my brain, I’d have thought I’d imagined a French version altogether.

kero kero kero, en avant les amis~

In June I leave my API engineer job at Pictarine on good terms, and before I find a new job in Bordeaux, I have some free time. So I put that time to use: I want to find the French dub of Keroro Mission Titar!

The story of the French dub of Keroro Mission Titar

When you look into how Keroro was produced in France, you quickly understand why it’s a lost media today.

Even talking about a single French dub is a bit of a stretch, because two studios actually followed one another to dub the adventures of the frog platoon. The first 13 episodes were dubbed by the French studio Mediadub International, then redubbed by Made In Europe and Agent Double, Belgian studios which were then tasked with dubbing the 103 episodes of seasons 1 and 2. The episodes aired on Télétoon and IDF1, but there was never any physical release. It’s impossible to get hold of a legitimate copy, even second-hand.

So, who do you convince to rebroadcast Keroro?
It was Rouge Citron that bought the French broadcast rights from Sunrise and its partners, then commissioned the dub from Mediadub International… Except Rouge Citron filed for bankruptcy in 2007 and the exploitation rights to Keroro were taken over by Media Participations (the group that owns ADN and Kana), which commissioned the Belgian dub.
It’s also worth noting that the original rights bought from Sunrise possibly had an expiration date too, so convincing Media Participations to rebroadcast the series through ADN or Kana Home Video wouldn’t necessarily be enough either…

📝 Note
This is my personal opinion, and doesn’t bind any other organization of which I may be a direct or indirect representative.
Unauthorized sharing of copyrighted works is illegal in France, including in situations where the rights holders are not distributing the works in question.

I won’t go into my full opinion on the modern copyright system in France or elsewhere today.
Let’s just say I wouldn’t shed a tear for a company holding the exploitation rights to a treasure of my childhood and choosing not to exercise them, “cheated” by the resurrection of a work that made the child I was laugh so much.

Keroro Mission VF

On June 3, 2026, I join a Discord server of enthusiasts who are going all out to try to find this lost media: Lost Media Keroro Mission VF. I go through every channel, learning about everything that has been tried, every dead end, every person who worked on this dub and was contacted by fans. The community has moved heaven and earth for the sergeant frog.

And these efforts aren’t in vain: some episodes have been found and shared on the YouTube channel Keroro VF Archives. So there’s hope, these episodes do exist somewhere, we just have to find them.

We won’t have to wait long. On June 7, a moderator makes a server-wide announcement: Episode 62 was just found on eMule.

@everyone hello everyone!
Great news: a new episode has been found on eMule!
It’s episode 62!
Fingers crossed we find more!
In the meantime: enjoy watching! ⭐
Ps: the original file name was [TV] KERORO MISSION TITAR N°062A « Les demoiselles cambrioleuses » [Dimanche 21 septembre 2008 à 16H50 sur TELETOON].avi in case it helps ~

I want to help, and if one thing is certain, it’s that we need to scan eMule more carefully.
Let’s be clear: ed2k and Kademlia aren’t exactly the hot technologies of 2026, they’re things I used to hear my parents and their friends talk about when I was a kid. The existing tooling is fairly basic, and not exactly abundant. A UFO named aMule still hovers over the ecosystem though, and thank goodness: it’s lucky a modern fork of eMule exists.

Armed with my client, I run a search here and there, without much success.
I have to resign myself: if I want to do this properly, I need a crawler running 24/7.

Building an ed2k/kad crawler

On June 10 I dive in, no way I’m missing new episodes.
Anything that could be a lead must be recorded somewhere, and if it’s promising enough, I must absolutely be notified and the file must be downloaded automatically.
I’m embarking on an adventure of more than a month, at a rather uneven pace.
Assisted by a Claude Opus acting as developer, I put on my best architect’s hat, the goal being an eMule crawler that misses nothing and is smart enough to separate the wheat from the chaff.

The principle behind Mulewatch is a loop: search -> sort -> catalog -> act.
To do this filtering efficiently, I start by selecting eMule search keywords, then build negative filters from them to exclude files that are, beyond any shadow of a doubt, not the French version of Keroro Mission Titar. In the end, contrary to what I expected, there are few absurd false positives; with keroro and titar as keywords, I get almost exclusively relevant content, apart from a few oddities.

Of course, that’s without accounting for the fact that non-French-speaking communities are in the majority. So I have to surgically find UTF-8 characters, naming conventions, or words that let me keep only the French dub, without being overzealous either: it would be catastrophic to wrongly exclude a French-language episode.

I run into edge cases, since that’s always what happens when you point a program at a stream of data from the Internet. Should we keep keroro.avi? And keroro.zip? It’s not explicitly the French dub, but it could be, and it’s impossible to be sure upfront, we can’t exclude it without checking by inspecting the contents. We need something more granular than in/out, we have to assign a score to a file based on its name. But what makes one file more promising than another? We already got a clue when we found 62A, with its particularly conscientious naming:

[TV] KERORO MISSION TITAR N°062A « Les demoiselles cambrioleuses » [Dimanche 21 septembre 2008 à 16H50 sur TELETOON].avi

Several things might make you raise an eyebrow, but let’s start from the keywords keroro and titar, which would already find this file.
First, the full string “Keroro Mission Titar” is the French name. Télétoon is indeed a channel on which the anime aired. Sunday, September 21, 2008 is indeed within the expected broadcast period.
But we could just as well have a fan redistributing adjacent files, like press reviews, screenshots, ads, assets… In short, things we’re interested in, but not the treasure.
This kind of clue, indicating that we’re really dealing with French-language Keroro content, forms the notify tier, which, as the name suggests, can notify me through any method supported by Apprise.

No, what’s conclusive here is mostly .avi, 062A and Les demoiselles cambrioleuses: going by the episode list of Keroro Mission Titar, that matches an episode perfectly, there’s no possible doubt about this file name. So I put all these target episodes in a data file, and any file whose text comes close to an episode name is accepted into the download tier.
Sure, we could be dealing with a prankster sending a completely different video under this file name, but rest assured, the amount of finds to sort through by hand isn’t exactly gargantuan.

Initially I plan very big, and in v1.0 Mulewatch is a complex Docker Compose setup.
A crawler, a ClamAV checker, aMule, gluetun, prometheus and grafana.

Mulewatch architecture diagram at its announcement

I’ll admit it’s total overkill for a crawler, but I figured I might as well do things right from the start.
Custom Prometheus metrics with a Grafana dashboard could have helped diagnose problems in real deployed behavior. The checker with ffmpeg and ClamAV, plus the Freshclam container to update the definitions of dangerous files, would have avoided keeping dangerous or… dubious files. eMule forged itself a sad reputation, rightly or wrongly.

Except that in practice, we have logs, and we already have the matching engine in the crawler to refine what’s kept or not. I’d later decide to prune Mulewatch to make it simpler to maintain, debug and deploy.

On July 5, I get confirmation that the Mulewatch bot works as intended, because it independently finds episode 62A. It’s encouraging, and I get a fresh burst of energy. I have to publish this bot and let it run! I improve the matcher, clean up the code a bit, and on the 20th I send a message in the community Discord to announce Mulewatch.

I let it run, but quickly, with no new interesting content, I kind of forget about it.

First blip on the radar

Faithfully, for the rest of July and all of August, Mulewatch keeps watch.
But nothing, nada. Maybe it was a secondary source, and in the end there would be nothing on eMule? Of course, it would have been a serious mistake to shut down my gas factory over this prejudice.

On September 11, I decide to take a look at Mulewatch’s catalog after letting it run in its corner for more than 2 weeks.

Mulewatch has cataloged 8 new episodes, spotted since September 1st.
It saw 65A, 65B, 66A, 67B, 68A, 68B, 69A, 69B.
And none were downloaded. Not because the file wasn’t recognized, no, but because my aMule connector had a bug. What a disaster…

I alert the community, and a “Keroro Mission eMule” team forms.
We quickly realize that 62A was indeed an isolated case, its source “MiaoussMalicieux” doesn’t seem to have any other complete episodes of Keroro Mission Titar.

Every day, a new episode is detected at 00:01, shared by a mysterious source named “AnimuseeFMR”.
They limit their uploads to 1KB/s, a rate split across 2 download slots.
Another difficulty: AnimuseeFMR has what’s called a “low id”. That means we need an open port on our own router to communicate and get data, and we need to be connected to the same ed2k server for the negotiation required to start the download to begin.

No, you didn’t misread, and it’s not a typo, I do mean 1KB/s.
So in theory, we have a maximum limit of 86.4MB (82.3MiB) downloadable in 24h.
That’s an important threshold, because every day, religiously, AnimuseeFMR stops sharing the current file and moves on to the next one. An episode bigger than the limit won’t get through within the day, it’s physically impossible.

Episodes 70A to 76A follow one another, all too long to fit in a full day of downloading without losses. Every day we try to get 50% of the download, hoping that one day the source will loop back and we could then complete our partial downloads…

Interlude: De-gas-factorying Mulewatch

OK, it’s all well and good to catalog episodes, but we should actually download them.
Fixing the download itself is a mundane patch, but if we can also make Mulewatch’s architecture diagram look less like a bowl of spaghetti along the way, that’d be nice too.

Let’s start with “Do one thing, and do it well”.
A bot hunting for lost media doesn’t need an antivirus or a full observability dashboard.

The number of files found is small by definition, so it’s acceptable to delegate verification of downloaded files to the operator. For debugging and operational monitoring we have logs, no need to suggest Prometheus and Grafana by default, that’s more a thing for observability nerds (-> read: pejorative) than for a lost media hunter.

On September 13, I make these two cuts and things already look clearer:

Mulewatch v2.0.0 architecture diagram

Why do we need a docker-proxy container, by the way?

To get a high id and discover as many ed2k/kad sources as possible, you need to be reachable through a port exposed to the internet. The alternative is having a low id, and being unable to contact other low id clients. Not ideal for a crawler.

If you expose a port directly in your router’s NAT section, it’s fairly simple.
But if you use a commercial VPN through Gluetun, you can’t predict which port will be opened at the provider and then announced by Gluetun, so we have to query it regularly and then apply the port in amuled’s settings.
Except amuled doesn’t support changing the port on the fly, you have to restart its container to apply the change.

On principle I’m not a fan of letting my homemade crawler restart any container by giving it direct access to the docker socket, so I only expose the restart of container_name: amuled through a proxy designed for that.
It prevents honest programming mistakes but also the impact of LLM blunders, and it slightly reduces the attack surface if the crawler were ever compromised and allowed remote code execution (RCE).

Except nothing says we absolutely need two different containers!
And if both processes are siblings, we can use a system like s6-svc to orchestrate them properly and restart amuled from the crawler when needed.

It requires a bit of trickery because Debian’s repositories don’t ship a recent enough version of aMule. To work around the problem, and to avoid recompiling aMule (foreshadowing), I decide to bundle it as a nix package, installable on Debian without too much trouble.

Yes, I know: “Sacrilege, one container = one app”.
But an app is an arbitrary concept, nothing says we absolutely must have one process per container. If we decoupled the crawler container and the search / download client, we’d keep paying a heavy price with an architecture that’s not really suited and more complicated than necessary. So for v2.0 we bundle amuled in the crawler container with nix, and orchestrate everything with s6.

Mulewatch intermediate architecture diagram

OK, not bad, we’re almost there.
Now, what are these communications to amuled labeled “EC”?

To control the amuled process from the outside there was only one choice, and that’s to speak “External Connections”, EC for short, a binary protocol over a TCP socket. Nothing insurmountable, especially when working with an open-source app, but not very convenient.

With aMule 3.1.0, amuleapi was introduced. It’s both a new web interface replacing the dated and incomplete amuleweb interface, and a REST API to drive amuled. You might think that in a project that depends so much on its ed2k/kad client, this would be a painful and error-prone rewrite, and it would be if I hadn’t designed the crawler to strictly follow Bob Martin’s Clean Architecture.

Software architecture aside

It’s true, writing domain, ports, adapters is more verbose. But when you need it, goodness, how satisfying it is to swap one adapter for another and be confident there are no side effects thanks to a well-thought-out design! And in the age of agents, it would be reckless not to buy yourself peace of mind by design when you know a Claude will knock out this extra decoupling work without it even showing up in the time budget.

I believe we’re in an era where software architecture and system design can dictate the life or the suffocation by immediate technical debt of a software project. Everything goes faster, and the margin you used to have for taking shortcuts in code before paying the price of architectural flaws shrinks proportionally to the speed of coding agents.

Aside over, we’ll need to bundle aMule 3.1.0 to take advantage of this great API and Web UI.
We need to talk software distribution, because since mulewatch v2.0 we already bring in aMule from a different source than the rest of the packages. That wouldn’t necessarily be a problem in itself if the nixpkgs repository were overseen by expert and trustworthy people, but anyone can approve a PR to change a package.
How horrifying!

It’s not consistent to rely on Debian for stability and its reputation for seriousness on one hand, and on the other bundle a package that can be modified at any time by anyone.

Had I dug deeper to learn more about nixpkgs, I wouldn’t have used it for a deployed app, especially since I care about supply chain security on Mulewatch: signed Docker image, declared SBOM, daily CVE scan and VEX to exclude false positives. We definitely can’t keep a dependency on nixpkgs; if we want to bundle aMule 3.1.0, we’ll have to install its dependencies and compile it ourselves.

Mulewatch v3.0.0 architecture diagram

Mulewatch’s architecture is now in an acceptable state, and we can get back to the search.

First complete file

On September 28 at 00:02, we saw episode 76B appear in the search results.
To say the least, we were hopeful. In reality, we were overjoyed!

Overexcited Discord conversation between Willex and DL21 about episode 76B

And we were right to believe, because at 18:48 DL21 had the complete file.
In general euphoria, we found the episode [TV] KERORO MISSION TITAR N°076B « Emmène-moi sur la lune 2 » [Dimanche 05 octobre 2008 à 11H10 sur TELETOON].avi 🎉

Today, the half-episode is saved

With several lost media researchers,
On the ed2k/kad network,
On archive.org,
In the bittorrent DHT,
On YouTube (soon),

Fun fact: the bittorrent DHT is based on Kademlia, the protocol also used by eMule. The kad in ed2k/kad stands for Kademlia! That said, the two networks are incompatible with each other, they only share a base protocol.

Merging incomplete ed2k data between peers

In case you’ve forgotten, the ed2k protocol isn’t exactly young, coming from a time when top-tier residential bandwidth was a few KB/s. It isn’t as permissive as bittorrent in how it splits files: a part can only be re-shared with other clients once a data block of ~9MB is complete. Before that, we have data, but it’s impossible to redistribute it to peers.

This coarse splitting works against us when dealing with low upload speeds, since nothing guarantees that we’ll be able to download an entire part and therefore redistribute it in turn. In the worst case, all clients can in turn get the same part #N and complete it to 99% from a slow source, and the amount of unique data obtained is minimal. In an ideal world, each client could re-share what it received and there would be no duplicate transfers, but we can’t act on the design of a protocol that has been outdated for 20 years, we have to live with it.

But aMule’s .met and .part files are nothing mysterious, and it’s perfectly possible to combine the incomplete downloads of two peers into a more complete one, a union of bytes.
DL21 came up with this hypothesis and a few hours later, she shared a proof-of-concept script to merge incomplete downloads. A few more hours later, I converted the script into a serverless web app, running entirely in the browser to do this merging in bulk.

Source code: https://github.com/mission-titar/amule-part-merger
Web App: https://mission-titar.github.io/amule-part-merger/

Screenshot of amule-part-merger showing the reconstruction of episode 76A

In this example, the result is striking: the video file resulting from merging 3 peers gains 27.7% compared to the common parts shareable by ed2k. Three of the clients had each obtained an almost complete part, and this data couldn’t be shared through ed2k, so we pool it using the tool.

The benefit, besides optimizing the source’s bandwidth when the file is shared again, is that we can watch the video file at length without trouble in VLC, and the missing data is a bit of the pre-credits plot. We can watch both parts of episode 76 (almost) in full, thanks to a trick to overcome the weaknesses of the ed2k protocol.

Conclusion

Today, we’re still on the lookout, with the goal of finding all the episodes of Keroro Mission Titar.
Lost media research was a corner of the internet I didn’t really know before, and I found people there with unfailing motivation and perseverance. It’s a very enjoyable experience, and I’m a bit stunned to have made a fruitful contribution and brought tools to the community of Keroro VF researchers.

It’s a bit cheesy, but in the end what let us succeed is perseverance.
Thanks to DL21, Gaoura, Kanari Raspberry, UniversJB, and all the other community members who supported the small team of eMule soldiers.

If our estimates are right, we could possibly get all the episodes of the French dub within a year, assuming the source loops back over the previous episodes. That said, we fully intend to keep racking our brains and turning the whole internet upside down to find these episodes.