[Naugas]

I'm using linux, but did try to run the win gui under mono first. It didn't work at all - but then I saw a notice at the bottom that said it wouldn't work on network shares, which is where all my anime is. By the time a folder/series had been copied to a local disk I was almost finished with getting the native script to work, with all the perl modules needed. Didn't even know that perl had it's own module system and installer before this.


Anyway - to the Kodi developer that might take a look in this thread - pretty please make a plan for incorporating these matroska functionalities into Kodi. There's a thread that suggested it could be a Google summer of code project - http://forum.kodi.tv/showthread.php?tid=220746 - but it was never accepted. I have quite rudimentary knowledge about programming in general, but it shouldn't be that much work to implement this? References and switching to other files and streams at playback?


There are many anime encoders that use ordered chapters all the time, and I've never came across it anywhere else, so if you don't watch anime I do admit it's of little use. But the last year I've come across it more and more, probably because I've started to look for small and efficient encodes that doesn't waste hard disk space. Of course, there seems to be other uses and applications as well - things that doesn't mean much to me, but is needed by others.

[garretn]

The GUI is a separate/unrelated project by someone else, and I believe uses it's own modified version of UnlinkMKV.

In terms of network shares it depends on how you access those shares. All of my Anime is on a home server, but since I mount those shares via NFS to my local system unlinkmkv works just fine with it.

Agreed on actual support in Kodi though, but don't count your chickens. The actual problem of doing it is very complex if they want to support the matroska features properly, which is far more complex then how typical fansub groups use those features. I saw someone try to do a GSoC but they didn't get any backing from what I could see.

[metal450]

Not that this really contributes anything to a solution, but to the Kodi developers, consider me +1 more voice who really wished this worked.

I use Kodi for everything - except Anime, for which I have to use a different video player (and which means I can't ever watch it on my TV, which isn't hooked up to an actual computer but a 'thin' Kodi-only box).

[garretn]

Not that this really contributes anything to a solution, but to the Kodi developers, consider me +1 more voice who really wished this worked.

I use Kodi for everything - except Anime, for which I have to use a different video player (and which means I can't ever watch it on my TV, which isn't hooked up to an actual computer but a 'thin' Kodi-only box).

For what it's worth you could try UnlinkMKV for Anime, a while back I updated it to support windows and you can find a precompiled bundle in the github dist directory w/ all the needed tools included. Hopefully someday someone more talented will add support to Kodi for linked segments.

[metal450]

For what it's worth you could try UnlinkMKV for Anime

...At the cost of unnecessarily increasing the disk space required by every single series, by duplicating the same video portions over & over again... :/

[garretn]

For what it's worth you could try UnlinkMKV for Anime

...At the cost of unnecessarily increasing the disk space required by every single series, by duplicating the same video portions over & over again... :/

Pretty much.

[DJ_Izumi]

If you guys are worried about the amount of space that redundant OPs and EDs consumes when unlinking the MKV, I think you might want to address your critical storage problems.

[metal450]

If you guys are worried about the amount of space that redundant OPs and EDs consumes when unlinking the MKV, I think you might want to address your critical storage problems.

...Um, actually, no. Many serieses have dozens and dozens of episodes (or more), which in high res can total to gigs of totally redundant (and pointlessly redundant) data. Even if storage were free and infinite, which it isn't, there are many scenarios in which you CANNOT increase storage. Like tablets or small/ultraportable laptops.

[Daemonax]

For what it's worth you could try UnlinkMKV for Anime, a while back I updated it to support windows and you can find a precompiled bundle in the github dist directory w/ all the needed tools included. Hopefully someday someone more talented will add support to Kodi for linked segments.

Thanks for making this, found that someone has created a git package in the Arch User Repo, so installation was easy. Luckily I have only two files that have opening pieces split from them. Do wish that kodi would support split files though.

[Smeulf]

Hi everyone.

As many of you, I'm very interested with a full support of the MKV specifications by Kodi. I know it's very related to ffmpeg, and maybe it still won't be possible now, but I also can see a lot of confusion between all terms.

As I have some knowledge with MKV, I'll try to explain "Editions" "Ordered Editions" and "Segment Linking" :

Editions : A set of chapters. You can have many ediiton in a MKV, with different chapters with different start points. An edition can be set to default, if none is set, the first is considered as the default one. An edition can be hidden (don't know why it could be usefull, but it can ^^)

Ordered Editions : Same as an edition, but all chapters have a start time and an end time. "Abusively" called "Ordered chapters". It creates a virtual timeline for a movie. It's very usefull when you have a long version movie. An edition can contain the basic movie, an another the movie with the extended movie. Also very usefull for director cuts : One edition for the "normal" movie, one for the rearranged version.

Segment linking : Every MKV contains it's own ID, called Segment ID. By referencing this segment ID in the chapter, you tell the player it must use an another mkv file to play the streams. All linked segments must be in the same directory (IIRC). Mostly used in Animes, because you can then encode the opening and the ending once, and call them for every episodes.

All those specsifications can be combined to produce a very advanced MKV.

Also just a note about the chapters : They can be enabled or not (must be played or not), and hidden (an hidden chapter must be played if enabled, but should not appear in the chapter list).

Now about my own point of view, I'd be very happy if Kodi could fully support Editions, then Ordered Editions, respect the default edition, and respect at least the hidden chapter flag.

For segment linking, I can understand it's an another problem about implementation.

I hope that post can make you Kodi guys think again about full MKV support, and hopefully we can have it Kodi 18 maybe ? ^^

All the best.

Smeulf.

[skylarking]

If you guys are worried about the amount of space that redundant OPs and EDs consumes when unlinking the MKV, I think you might want to address your critical storage problems.

Ah, a critical storage problem can be resolved by a data deduplication solution and this does not involve simply buying more HDD's
DD is used my many large companies
I'd say get with the times

[skylarking]

Hi everyone.

As many of you, I'm very interested with a full support of the MKV specifications by Kodi. I know it's very related to ffmpeg, and maybe it still won't be possible now, but I also can see a lot of confusion between all terms.

As I have some knowledge with MKV, I'll try to explain "Editions" "Ordered Editions" and "Segment Linking" :

Editions : A set of chapters. You can have many ediiton in a MKV, with different chapters with different start points. An edition can be set to default, if none is set, the first is considered as the default one. An edition can be hidden (don't know why it could be usefull, but it can ^^)

Ordered Editions : Same as an edition, but all chapters have a start time and an end time. "Abusively" called "Ordered chapters". It creates a virtual timeline for a movie. It's very usefull when you have a long version movie. An edition can contain the basic movie, an another the movie with the extended movie. Also very usefull for director cuts : One edition for the "normal" movie, one for the rearranged version.

Segment linking : Every MKV contains it's own ID, called Segment ID. By referencing this segment ID in the chapter, you tell the player it must use an another mkv file to play the streams. All linked segments must be in the same directory (IIRC). Mostly used in Animes, because you can then encode the opening and the ending once, and call them for every episodes.

All those specsifications can be combined to produce a very advanced MKV.

Also just a note about the chapters : They can be enabled or not (must be played or not), and hidden (an hidden chapter must be played if enabled, but should not appear in the chapter list).

Now about my own point of view, I'd be very happy if Kodi could fully support Editions, then Ordered Editions, respect the default edition, and respect at least the hidden chapter flag.

For segment linking, I can understand it's an another problem about implementation.

I hope that post can make you Kodi guys think again about full MKV support, and hopefully we can have it Kodi 18 maybe ? ^^

All the best.

Smeulf.

Thanks @Smeulf, that's informative.

I'd also like to see MKV Ordered Edition support within Kodi as i have many BD rips of both cinema release and extended version sitting on my HDD.
Implementing this feature within Kodi would provide a nice deduplication solution of sorts

Then it's just for me to learn how to rip my BD's to capture both versions in the one MKV utilizing this Ordered Edition feature

[mojo-hakase]

Hello everyone.

As i use Kodi to watch Animes and also have some files that use ordered chapters, i'm looking forward to this feature being supported by Kodi.
So i've worked the last days implementing this feature and, so far, got a working version:
https://github.com/mojo-hakase/xbmc/tree...edChapters

What i have done:
I added a new demuxer: DemuxTimeline. That demuxer will be created, if the input stream is a matroska file with ordered chapters. It creates the virtual timeline from the ordered chapters, searches for linked segments and opens a FFmpegDemuxer for every extra segment. If the video is played, the demuxer transparently switches between the real FFmpegDemuxer.
That playing part is IMO well written and works fine.
The actually problem with this code is the timeline-creation part. What i needed to do there was opening the file a second time and parsing the mkv by myself, which is stupid, because ffmpeg has already done that.
I agree with the ffmpeg devs who has refused supplied user patches to support ordered chapters, because i think segment ordering and linking shouldn't be done by the low level demuxer, but by the actual video player. However, ffmpeg should parse and save all mkv properties, like editions and ordered chapters flags, and expose it to the programmer. Then i wouldn't need to parse the mkv a second time.
I fully agree with this "libavformat mkv checklist" by the mpv devs:
https://github.com/mpv-player/mpv/wiki/l...-checklist

At the moment multiple editions are not supported by my code, but could be easily implemented. The only problem is i don't know how the user interface can be implemented.

The next step will be beautifying the timeline-creation part, as it is quite ugly at the moment, and the make a pull request.
After that i will try to find a solution how ffmpeg could expose the parsed matroska propertys.
Then implement other mkv features.

If the pull request will get accepted, we could have ordered chapters and segment linking support in Kodi 17!

If there are any programmers reading this are interested in my code and want to help me, i will appreciate the help.

[Kib]

If the pull request will get accepted, we could have ordered chapters and segment linking support in Kodi 17!

Although this will definitely not be accepted into v17, it is very nice to see that you have taken it up on yourself to develop this.
v17 is already past the beta stage and heading for release so there will be no more new features added. However this also means that v18 is open for changes.

I would recommend to rebase and open a pull request against the master branch just to get some feedback on your code. This way you can get feedback on the proposed implementation. You can put "RFC" in your pull request so everyone understands you are looking for feedback and not ready yet.

ps - I am not a coder, but just trying to help a bit with the process here
ps2 - nice 2nd post

[Martijn]

PR is already open