[wsnipex]

https://github.com/xbmc/xbmc/pull/11088 should remedy some of your issues

[wsnipex]

more fixes: https://github.com/xbmc/xbmc/pull/11157
please test

[Max_nl]

https://github.com/xbmc/xbmc/pull/11088 should remedy some of your issues

It now seems to be building libdvd from source.
While that should not be necessary, as libdvdread/nav/css is already installed as shared library on the target system.

Code:

[ 13%] Performing build step for 'dvdread'
cd /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/project/cmake/build/libdvd/src/dvdread-build && /usr/bin/make
/usr/bin/make  all-am
cd /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/project/cmake/build/libdvd/src/dvdread && git log > /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/project/cmake/build/libdvd/src/dvdread-build/ChangeLog-tmp
fatal: Not a git repository (or any parent up to mount point /mnt/nfs)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Makefile:1006: recipe for target 'ChangeLog' failed
make[6]: [ChangeLog] Error 128 (ignored)
test -s ChangeLog-tmp && mv ChangeLog-tmp ChangeLog
Makefile:1006: recipe for target 'ChangeLog' failed
make[6]: [ChangeLog] Error 1 (ignored)

And fails at that.
(may be caused by that the build system I use does remove the .git folder with meta data after cloing the kodi repo, and it was not counting on that.)

==

Code:

-- [download 2% complete]
-- [download 5% complete]
-- [download 8% complete]
-- [download 13% complete]
-- [download 16% complete]
-- [download 26% complete]
-- [download 29% complete]
-- [download 32% complete]
-- [download 34% complete]
-- [download 37% complete]
-- [download 40% complete]
-- [download 42% complete]
-- [download 45% complete]
-- [download 48% complete]
-- [download 80% complete]
-- [download 82% complete]
-- [download 85% complete]
-- [download 88% complete]
-- [download 90% complete]
-- [download 93% complete]
-- [download 96% complete]
-- [download 98% complete]
-- [download 100% complete]
-- downloading... done

And you seem to be downloading extra sources from http://mirrors.kodi.tv/ without any warning to the user.
Besides that this breaks reproducibility of the build when that server is down or the file is removed at any point in the future, it also makes it harder for people distributing your software to comply with GPL.

==

Now expects JsonSchemaBuilder to be called JsonSchemaBuilder::JsonSchemaBuilder:

Code:

[ 29%] Generating ServiceDescription.h
cd /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/project/cmake/build && JsonSchemaBuilder::JsonSchemaBuilder /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/xbmc/interfaces/json-rpc/schema/version.txt /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/xbmc/interfaces/json-rpc/schema/license.txt /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/xbmc/interfaces/json-rpc/schema/methods.json /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/xbmc/interfaces/json-rpc/schema/types.json /mnt/nfs/kodi/buildroot-2016.11/output/build/kodi-Krypton/xbmc/interfaces/json-rpc/schema/notifications.json
/bin/sh: 1: JsonSchemaBuilder::JsonSchemaBuilder: not found
build/interfaces/json-rpc/schema/CMakeFiles/generate_json_header.dir/build.make:68: recipe for target 'build/ServiceDescription.h' failed
make[4]: *** [build/ServiceDescription.h] Error 127

Currently build JsonSchemaBuilder (and TexturePacker) outside of cmake and move it to $(NATIVE_PREFIX)/bin/JsonSchemaBuilder
Not sure if you are expecting it to be done a different way.

[wsnipex]

Re libdvd: if you want working dvd (also dvd iso) playback, you have to use our libs, since we carry some kodi specific patches.
Many distros fail to actually _test_ kodi properly after they got it to build with external libs and their users then come to us complaining that kodi doesn't work.

If you have a build sys that does not allow downloading anything during build, then you can provide tarballs like this:

Code:

-Dlibdvdread_URL="/path/to/libdvdread.tar.gz"
-Dlibdvdnav_URL="/path/to/libdvdnav.tar.gz"
-Dlibdvdcss_URL="/path/to/libdvdcss.tar.gz"

This works for a few other libs as well (e.g. crossguid)

https://github.com/xbmc/xbmc/pull/11158 should fix jsonschemabuilder

[Max_nl]

Re libdvd: if you want working dvd (also dvd iso) playback, you have to use our libs, since we carry some kodi specific patches.

And those patches aren't universal enough to contribute upstream?

Many distros fail to actually _test_ kodi properly after they got it to build with external libs and their users then come to us complaining that kodi doesn't work.

Could be.
But rather than putting all blame on the distros, I would argue that contributing modifications back upstream, and having a version check in your cmake, would be a better longterm solution...

If you have a build sys that does not allow downloading anything during build, then you can provide tarballs like this:

Well, if there is an absolute need for the modified sources, why not bundle them with the main source?

[wsnipex]

Re libdvd: if you want working dvd (also dvd iso) playback, you have to use our libs, since we carry some kodi specific patches.

And those patches aren't universal enough to contribute upstream?

correct.

Many distros fail to actually _test_ kodi properly after they got it to build with external libs and their users then come to us complaining that kodi doesn't work.

Could be.
But rather than putting all blame on the distros, I would argue that contributing modifications back upstream, and having a version check in your cmake, would be a better longterm solution...

see above. You're most welcome to try to send them upstream though.
also see http://forum.kodi.tv/showthread.php?tid=...ght=libdvd
As for testing: You ship software in a way not intended, recommended or supported by their creators. It is your responsibility to make sure it actually works.
Otherwise we kindly ask you not to ship it at all.

If you have a build sys that does not allow downloading anything during build, then you can provide tarballs like this:

Well, if there is an absolute need for the modified sources, why not bundle them with the main source?

That's how it was till ~1 year ago and it sucked. Rebasing on upstream was huge pita, specially with things like ffmpeg, where almost nobody wanted to even speak about using a new version, because our version was soo old and customized and entangled with xbmc core that it took a masters in git foo to even get a clean diff.
Those are dependencies and not kodi core code and we don't want dependencies in the kodi repo anymore. Thats why we made an effort to use upstream whenever possible and move the rest out to it's own repo where needed.

[Max_nl]

see above. You're most welcome to try to send them upstream though.
also see http://forum.kodi.tv/showthread.php?tid=...ght=libdvd

I don't think it is appropriate for me to take code I have not written myself and contribute that to another project.

As for testing: You ship software in a way not intended, recommended or supported by their creators.

Couldn't the authors of the libraries you forked say the same?
*mumbles something about a remark concerning code quality*

[Martijn]

see above. You're most welcome to try to send them upstream though.
also see http://forum.kodi.tv/showthread.php?tid=...ght=libdvd

I don't think it is appropriate for me to take code I have not written myself and contribute that to another project.

As for testing: You ship software in a way not intended, recommended or supported by their creators.

Couldn't the authors of the libraries you forked say the same?
*mumbles something about a remark concerning code quality*

Then ask him how cause so far no one has seen a way to send a pull request (although i see it's an option now) and there was also no response in past attempts (which was before gitlab iirc)

I already have a gitlab account but it seems you have to create another one (as i can't login) to send pull requests which is something i certainly won't do

[Max_nl]

Then ask him how cause so far no one has seen a way to send a pull request (although i see it's an option now) and there was also no response in past attempts (which was before gitlab iirc)

Maybe not as fancy as a pull request, but seems others have sent in patches in the past through the libdvdnav-devel list.

https://mailman.videolan.org/listinfo/libdvdnav-devel

[Martijn]

* Martijn freaking hates mailinglists and would like to nuke every single one of them into oblivion.

[wsnipex]

As for testing: You ship software in a way not intended, recommended or supported by their creators.

Couldn't the authors of the libraries you forked say the same?
*mumbles something about a remark concerning code quality*

no, because our users complain to us if kodi doesn't play dvds, not to videolan or whoever was the original upstream.

[ironic_monkey]

those patches are kodi specific things that cannot, shall not and should not go upstream. go try play a dvd over the network using your system libraries. no workie? woot. one would almost be tempted to say that the peeps that developed this software know what they are on about.

it's libdvdread which doesn't supply proper vfs hooks and it's kodi that has to deal with the short-coming.

this works through a link-wrapper that replaces posix io functions with implementations using the kodi vfs. those patches reflect limitations in the kodi vfs hooks. i could easily implement the stuff necessary to remove those patches, but it wouldn't help one bit. your system library will still not have the wrapping in place.

[Max_nl]

those patches are kodi specific things that cannot, shall not and should not go upstream. go try play a dvd over the network using your system libraries.

And Kodi is the only project that supports opening a DVD over a network stream

it's libdvdread which doesn't supply proper vfs hooks and it's kodi that has to deal with the short-coming.

Are you sure that is still the case in newer versions?
https://code.videolan.org/videolan/libdv...ader.h#L89

/**
* Opens a block device of a DVD-ROM file, or an image file, or a directory
* name for a mounted DVD or HD copy of a DVD.
* The second form of Open function (DVDOpenStream) can be used to
* provide custom stream_cb functions to access the DVD (see libdvdcss).
*
* If the given file is a block device, or is the mountpoint for a block
* device, then that device is used for CSS authentication using libdvdcss.
* If no device is available, then no CSS authentication is performed,
* and we hope that the image is decrypted.
*
* If the path given is a directory, then the files in that directory may be
* in any one of these formats:
*
* path/VIDEO_TS/VTS_01_1.VOB
* path/video_ts/vts_01_1.vob
* path/VTS_01_1.VOB
* path/vts_01_1.vob
*
* @param path Specifies the the device, file or directory to be used.
* @param stream is a private handle used by stream_cb
* @param stream_cb is a struct containing seek and read functions
* @return If successful a a read handle is returned. Otherwise 0 is returned.
*
* dvd = DVDOpen(path);
* dvd = DVDOpenStream(stream, &stream_cb);
*/
dvd_reader_t *DVDOpen( const char * );
dvd_reader_t *DVDOpenStream( void *, dvd_reader_stream_cb * );

Look like vfs hooks to me.
But no, I have not tested if they work properly.

[ironic_monkey]

interesting. they must be new. maybe we can kill this god damn hack once and for all. trust me, they weren't there. have fought this shit since 2004 on the xbox.

and yes, all other software i have encountered using dvdread required system level mounts for network access.but that wasn't my point at all, the point was that upstream cannot carry patches that reflect the limitation in kodi vfs hooks. everything else, some 5 patches i believe was sent upstream a few years ago as soon as an upstream re-appeared.

[Max_nl]

Looks like it has been added in January 2015.

Did notice it currently only seems to cover seek and read functions.
Don't know if it is necessary to add an openfile callback as well to cover the case in which a folder with multiple VOB files is opened (instead of single image file), and it wants a different file.
If so, I would still not label that as Kodi specifc code necessary to deal with Kodi's vfs limitations.
But rather suggest the addition of that hook as a generic hook that could also be used by other media players to support things like network streaming over protocols such as http.
That is not handled with system level mounts either after all...