SageTV 9 with HD300 can't read the duration of MKV files in Linux

[Narflex]

Originally Posted by stuckless

SO... If I create a new build, it would likely be 9.0.1.0. Should I commit the build number update back into your sources? (ie pull request to github).

EDIT: So, SageContstants has the build number, why isn't that in the Version.java long with the other build version parts?

I already have changed it to 9.0.1. But feel free to update the micro version anytime you want if you feel you've made a substantial enough change.

Ideally; the build version gets updated every single time a new version is created (for GitHub; every commit would be good). We had it in a separate file before because our scripts would then just update that one file with that value when it was creating a new installer.

If anybody knows how to make the build number increment on every commit; let me know. Or if there's some other way to pull a nice incrementing value to use in place of that; it'd be good too.

[Nelbert]

Originally Posted by Narflex

I already have changed it to 9.0.1. But feel free to update the micro version anytime you want if you feel you've made a substantial enough change.

Ideally; the build version gets updated every single time a new version is created (for GitHub; every commit would be good). We had it in a separate file before because our scripts would then just update that one file with that value when it was creating a new installer.

If anybody knows how to make the build number increment on every commit; let me know. Or if there's some other way to pull a nice incrementing value to use in place of that; it'd be good too.

Usually I would inject the build number as the continuous integration build job number from Jenkins or Travis. To use the short version of the sha code that github displays as latest commit number when viewed through a browser:

git rev-parse --short=10 HEAD

~/Projects/sagetv$ git rev-parse --short=10 HEAD
4ac1c547b6

To produce a longer version identifier then something like this:

git describe --always --long --dirty --abbrev=10 --tags

would generate as either:
<latest-tag>-<commits-since-tag>-g<short sha id>
or
<short sha id>
depending whether the repo is tagged or not

~/Projects/sagetv$ git describe --always --long --dirty --abbrev=10 --tags
a7a497fc91
~/Projects/sagetv$ git tag -a v9.0.1.0 -m "with tag version 9.0.1.0"
~/Projects/sagetv$ git tag
v9.0.1.0
~/Projects/sagetv$ git describe --always --long --dirty --abbrev=10 --tags
v9.0.1.0-0-ga7a497fc91
~/Projects/sagetv$ git checkout master
Switched to branch 'master'
~/Projects/sagetv$ git describe --always --long --dirty --abbrev=10 --tags
v9.0.1.0-4-g4ac1c547b6

The details are here https://git-scm.com/docs/git-describe but basically:
--always forces using just the short commit id if no tags exist
--long forces the long version even if the repo is currently at the tagged commit
--dirty add commits since the tag
--abbrev=10 shortens the full commit id sha to the first 10 chars which is the default display in github

The above commands could either export the value to an env variable or output it to a file as part of the build script and then imported in from the env var or file during the build.

At work we would use the 10 digit sha and our continuous build server job number together in the filename when building a deb or rpm package for nightly/snapshot/dev releases where it wasn't appropriate to tag the codebase before building. It made it very simple to trace back in Jenkins and Git from a package name.

I have a travis config which sets up a travis-ci.org build robot and then replicates the buildall.sh on every git checkin. I'm still sorting out the automatic upload to binfiles (it is currently failing at that stage) and was then going to look the best way to inject the git tag/version number in the pipeline so it automatically updated the version. I've not had much time this week so it stalled.

[wayner]

Originally Posted by jusjoken

So if we build it under 64 bit Linux do we get more memory to connect more extenders....ie: get past the 1024 limit in the 32 bit version or is there more to do to resolve that?

Any progress on this - and how best to do it? If I remember correctly there were at least two options (1) Run each client/miniclient in a separate JVM, or (2) use 64 bit Java and allow a much larger heap size.

[Monedeath]

Try posts 11 thru 15 in this thread... Before it was derailed a second time.