Feature

• Route for searching by AniList ID
  • Automatically redirects to the corresponding Jimaku entry
  • e.g. for the AniList URL anilist.co/anime/145728/-MERCHANT-MEETS-THE-WISE-WOLF/:
    • jimaku.cc/anilist?id=145728 -> jimaku.cc/entry/2272

Motivation

• This would enable creating a Tampermonkey script that adds a button to AniList anime pages that takes you directly to the corresponding Jimaku entry (if it exists)

Context

• Currently the Jimaku home page loads in every entry from the database all at once, much the same way as Kitsunekko does.
  • As Kitsunekko does not have a search bar, this is useful as it gives the user the option to search for a particular entry using ctrl + f.
• Since Jimaku has a proper search bar, it's not as necessary to load in every single entry when loading the main page.
• Currently when loading Jimaku it takes me approximately ~7 seconds to load on average.
  • I think it would significantly improve the user experience if this was reduced.

Ideas for possible solutions

1. Deferred loading

   • Only load entries when the user initiates a search.
   • This reduces the initial load time significantly as it avoids fetching and rendering all entries at once.

2. Data caching

   • Cache subtitle entries locally in the browser after the initial load.
   • Subsequent visits or searches can then use the cached data, reducing the need for frequent database queries.
     • I assume this would also require a mechanism to periodically update the cached data to reflect changes in the database, such as modified or deleted entries.

3. Incremental loading

   • Only load a portion of the subtitle entries initially.
     • As the user scrolls, dynamically load additional entries from the database in smaller batches.

4. Data pagination

   • Implement pagination for the main page to display entries in manageable chunks.
   • Only a set number of subtitles would load on a page, and the user could then click to go to the next page to see more.
   • This distributes the load evenly and prevents overwhelming the browser with a large amount of data at once.

5. Server-side caching

   • Server-side caching mechanisms (e.g., Memcached or Redis) to store frequently accessed data and reduce database load.

not always ass subtitles are convenient, and third-party conversion is additional actions. ass and srt subtitles only have a difference in formatting, so it seems to me that it wouldn't be hard to do the conversion before downloading on the client side. i'm using this website now and it converts instantly, apparently it doesn't take a lot of resources to do it.

I'm not sure where Jimaku is getting all its great subtitle files but Bazarr's current set of sub providers is totally lacking when it comes to jp subs.

I was wonder if it would be possible for the devs here to add integration of jimaku into bazarr. Bazarr provides some instructions and python boilerplate here

https://wiki.bazarr.media/Troubleshooting/FAQ/#im-missing-or-want-a-subtitle-provider-added-to-bazarr

Their API Template seems to be preferred but they also provide an alternative Page Scraping Template.

This would be a huge help to those of us who use Sonarr to download anime and want JP subs added in automatically!

Hi! On your site you have a link to a discord server. This is considered dangerous because people who don't know that discord is malware could accidentally click on the link and install malware on their computer.

In your PR you say that you don't want to remove the link. I understand that, but there are other options to consider.

• [ ] Add a Matrix space (or just one room) and bridge it with discord.

  t2bot can be used to create a bridge between Discord and Matrix. Alternatively, the bot can be self-hosted. This way people would be able to talk to each other without being forced to interact with discord. People who still use discord will be able to talk with people who have joined the matrix room.

• [ ] Add any other privacy-respecting communication platform. Session, Briar, Telegram, Simplex, etc.

• [ ] Add a warning that the users will see before they are forwarded to discord.

  When people click on the discord link, they should be warned about the consequences. If they click "ok", then you could redirect them to the discord website.

• [ ] Add a mailto link. Even though in the PR you say that there's a email address ([email protected]), it's nowhere to be found on the website. Consider linking it next to the other links in the footer.

Since DJT already has a Matrix space, we could actually help you moderate your Matrix space, if you don't want to bother with it. You still need to set up the discord bridge yourself though.

Feature

• Indicate whether "Anime" or "Live Action" is the page currently selected, e.g. by highlighting the text in the header

Motivation

• When switching between the two (in the process of uploading) I end up getting no search results and only then realize that I have to change to the other section. Looking at the URL helps, but having it highlighted would be easier.

When selectively searching for subs using the episode parameter, files are likely not returned if they use the Japanese name of the show.
This behavior can be primarily observed with live action entries, whose files usually follow this naming scheme:
<show_name_jpn>#<episode_number>.srt

An example using the following entry:

{
  "id": 4583,
  "name": "#Remolove: Futsuu no Koi wa Jado",
  "english_name": "#Remolove",
  "japanese_name": "#リモラブ 〜普通の恋は邪道〜"
}

Looking at the files (list truncated), only subs with Japanese titles are available.

[
  {"name": "＃リモラブ～普通の恋は邪道～＃10.srt"},
  {"name": "＃リモラブ～普通の恋は邪道～＃03.srt"},
  {"name": "＃リモラブ～普通の恋は邪道～＃05.srt"}
]

Searching for episode number 3 using the API doesn't return anything.

As a test, I reuploaded the subtitle for episode 5 using the full English name:
#Remolove Futsuu no Koi wa Jado #05.srt

Now, searching for episode 5 actually returns something:

[
  {"name": "#Remolove Futsuu no Koi wa Jado #05.srt"}
]

Interestingly enough, doing the same with the following entry...

{
  "id": 240,
  "name": "2.43: Seiin Koukou Danshi Volley-bu",
  "english_name": "2.43: Seiin High School Boys Volleyball Team",
  "japanese_name": "2.43 清陰高校男子バレー部"
}

...which has files with both the English and Japanese names of the show, it actually works fine.
Here's what you get back when searching for episode 5:

[
  {"name": "2.43.清陰高校男子バレー部.S01E05.スタンド・バイ・ミー.WEBRip.Netflix.ja[cc].srt"},
  {"name": "Ni Ten Yonsan Seiin Koukou Danshi Volley-bu 005.srt"}
]

This led me to assume that the S01E05 substring is the key for a successful match, but turns out that might not necessarily be the case:
As a test, I reuploaded yet another subtitle of entry 4583 using the JPN name, but this time with a season/episode format:
＃リモラブ～普通の恋は邪道～＃S01E03.srt

Unfortunately, searching for episode 3 still returns [].

I am aware that matching is done on a best effort basis, but perhaps the filtering mechanism could be improved?
Other example entries to test with: 2445, 4420

In https://github.com/Rapptz/jimaku/issues/10 I mention that when I'm trying to open /admin, I'm getting immediately redirected back to /. There's no docs on managing the server, so I had to try different things. I've figured a way to access /admin. Apparently, You have to edit the database and mark yourself as admin by changing the user flag from 0 to 1. I don't know if this is the correct way, or if this is the only way, but I suggest documenting it in the README.

Additionally, I suggest explaining how to manage the website because the /admin page is rather bare-bones.

• [ ] How to add, remove, users.
• [ ] How to assign someone as an editor.
• [ ] How to add, delete, edit subtitles.

As I mentioned in #10, there's not enough documentation about setting up the server. This PR adds some information about the locally created files and directories, but it doesn't address all the mentioned issues. Those can be addressed in a separate PR.

Since there's no Matrix space yet, can I ask some questions here instead?

When I ran the site locally, I noticed one strange thing. If you change an html file and reload the page, or even restart the binary, the page doesn't update. The new content is shown only when I re-run cargo run. I haven't studied the code much, but are the html pages being baked into the binary? Otherwise I'm not sure why it's happening.

Sometimes, when I run the server, I can't kill it with ctrl+c afterwards. Only kill -9 works. But sometimes it works just fine.

It is not documented where I should look for configs,databases,logs,leftovers,etc. By running lsof and find I could figure out that:

• the config is placed in ~/.config/jimaku,
• the databases are placed in ~/.local/share/jimaku,
• the logs are placed in ~/.local/state/jimaku.

Are there any other files that jimaku creates? I think, ideally they should be mentioned in the README.

Lastly, how do I access the admin page? Haven't quite figured it out yet.

Related to #7. Related to https://github.com/tatsumoto-ren/tatsumoto-ren.github.io/pull/28

As I said there, I don't know what to do with https://cdn.jsdelivr.net/npm/@scalar/api-reference yet, but if this is merged, all pages except the API reference should work fine.

Feature

Add a new key to an entries metadata that displays the amount of files associated with said entry, e.g.:

{
  "id": 729,
  "name": "Sousou no Frieren",
  "files": 109, # <----
  ...
}

Motivation

Some shows, mostly unverified and externally imported ones, only have archives instead of uncompressed subtitles uploaded.
As such, the amount of files is often times much lower than the shows episode count.
(Of course, one also needs to take into account the amount of currently available episodes for currently airing shows)

Knowing the beforehand would make it possible to estimate if an entry only has archives uploaded. This could save one API call for every files query because we'd be able to make an educated guess whether to use the episode parameter or not.
(Many archives have names that seem to elude the episode number matching algorithm, so nothing would get returned)

Perhaps the key could even show the amount of archives vs uncompressed subtitles to facilitate an even more 'accurate' guess.