After transcoding videos to h265 by replacing the original video file, they can't be reached again through website

[Joaquín Gamonal]

Describe the bug
A clear and concise description of what the bug is.

After transcoding a clip, be it through Handbrake, Tdarr, etc, the clip is no longer available on our fireshare's website.
My Tdarr settings are default and set to .mp4 extension, fireshare does not seem to work with mkv yet, but im trasncoding to save a lot of storage space.
When X transcoding service ends, it replaces the original file that fireshare already processed with another with the same name, and with this and considering fireshare will not delete already processed files and will not re-scan files that considers it already knows (because they have the same name and most metadata) it will make the file unplayable through web (reporting a 404 error on website console)
To Reproduce
Steps to reproduce the behavior:

1. Upload a clip through fireshare
2. Set-up transcoding from another server (like Tdarr), or download the file from the server, transcode it via handbrake/ffmpeg then upload it again with the same name. Files must be transcoded to .mp4 extension
3. See error, file will no longer be playable on website and won't be re-detected by fireshare even after a restart

Expected behavior
Transcoded files should be able to be played and/or fireshare should be able to re-process files

Desktop (please complete the following information):

• Browser: Tested on Edge and Opera GX. Same 404 error

Additional context
Used to work fine without transcoding, so my configuration is not wrong, it's properly working if files don't get transcoded. The purpose of transcoding is reducing filesize (i've seen up to 60% reduction with default settings) without significant quality loss so it's way faster for clients and better for our local storage

edit: I tested again with another clip. Previous clips that I tested are not reachable anymore, even if I delete them from the server and upload again. I uploaded another small clip now, let it transcode automatically, and now there are 2 different videos that point to the same file, and as expected, deleting one of them deletes the file

[Shane]

This isn't a bug, what you are doing completely breaks how fireshare works.

1. If you read the docs, h265 is not reccomended to begin with because most browsers do not support it and cannot play it.
2. Even if you do use h265, transcoding and replacing the file AFTER fireshare has already scanned it in is going to break the database. You need to transcode your files BEFORE you give them to fireshare.

Why does this break fireshare? When fireshare scans a file in it creates the symlinks and names them based off a hash of the files original data. If you change that data (i.e transcoding it and replacing the original file) it no longer matches and the database is going to be out of sync.

So what you need to do is change the order in which you do things. Place your files somewhere, have Tdarr or whatever your transcode service is transcode them and then move them to fireshare.

However, like I mentioned before H265 is not very well web supported, so while fireshare will have 0 problems serving h265 some browsers may not be able to play the videos.

[Joaquín Gamonal]

Makes complete sense. Thank you very much
I was thinking of an idea this morning, that may be better as a separate feature request if it fits the Fireshare project. I was thinking to not make users get outside of the fireshare instance as you suggested, to make it simpler for users

The idea is still being able to upload through fireshare to certain folder, and, if marked in the docker/instance settings because this should not be default, make fireshare not scan that folder, instead scan other folder where files will be dropped in by another software. This eliminates this problem, allows most users to transcode their videos automatically (even already in h264 but with a lower bitrate) to save 50+% space and bandwidth, and makes it simpler for the clients.

PS: I've been reading the code, and fireshare is already doing transcoding from .mkv to mp4 using ffmpeg. that section could be adapted with a non-default setting to set custom ffmpeg parameters, or being able to work with already existing transcoding software, but expanding more on this idea may require to open a proper feature request