No offense Ruben, but I guess you did not get my point. I'm kind of sad
that you have taken my comments that personal and seem to feel that much
offended.
Anyway, next time I'll mind my own business and fix the issue locally.
The last thing I want is starting a fight about something that is
already working.
This is what I want least. We are all commiters in an open source
project and we have to take responsibilities in this project. If we see
that something is broken and we think that we are able to fix this we
have taken the responsibility to do this. And doing code reviews and
reacting on comments there is something that we as commiters have
commited ourselfs to.
You are completly right: we lack support to backwards compatibility.
That is unfortunate. And I welcome any improvement that increases this.
But just in general (not for this particular issue) who should improve a
patch that is not completly finished yet? I fear that ideas about paid
membership models for Matterhorn will look much more promissing if we
see that devs are not willing to go through the whole QA process with
their code. The we will need a large paid bugfixing and QA staff. And I
would hope that the community will stay strong enough that we don't need
these memberships.
Rüdiger
Am 08.11.2012 11:54, schrieb Rubén Pérez:
Rüdiger,
I'm all +1 to the namespace change, and I voted as such in the
relevant thread. I'm not complaining about improving this part of
Matterhorn, which was certainly necessary.
That being said: since the project started we have been unable to keep
backwards compatibility between Matterhorn version. I'm not talking
about external products or vendors. I'm talking that there is no
upgrade path from 1.0 to 1.1, from 1.1 to 1.2 and from 1.2 to 1.3.
The only way to upgrade was basically start from scratch and ingest
everything again. That is really worrying, specially when we talk
about a system that can potentially handle Terabytes of information. I
know no other piece of software where you cannot keep your data
between versions, or that does not provide an automated way of
converting your data. Fortunately, the inmense amount of little
glitches and bugs that Matterhorn used to have (and still has, to some
extent) made it unsuitable for a real, large-scale production system,
without a good amount of hard work. This is luckily changing, but
until 1.2 it was unsanely difficult to keep a stable production system
with a reasonable amount of recordings being ingested everyday.
For the record, we've got 1.2 in the UVigo and we are still here
because we are afraid of what it will take to move all the current
recordings to a 1.3 or 1.4 system. It would mean about one week, 24/7
processing time to take all the video sources and reprocess again with
the qualities they are now published. It's not something that we can
afford in the long run.
The namespace case is just another facet of the same problem. You've
got your 1.3 CAs that produce 1.3 MediaPackages and you want to ingest
them in a 1.4 core. You simply can't. *I'm talking about official
Matterhorn products, not vendors.* We are basically saying the
adopters "I don't care what you want, you have to upgrade your CAs
too". And i wouldn't make such a fuss about this if upgrading a CA
meant nothing, but it does. We are everyday seeing reports that the
confidence monitoring is broken in the 1.4 CAs, that the VGA support
is completely broken (and not just because the Kangaroo Patch was
removed), and who-knows-what more small issues and glitches that we
have made our adopters to get accostumed to, and don't show up in the
list anymore. So, to sum up, we are forcing our adopters to choose
between a buggy CA or nothing at all. Or forcing them to patch the
code themselves, as Rute did, because we didn't give them an alternative.
Galicaster does support the new namespaces --we were going to wait for
the 1.4 release, but after some users requested it, we were about to
release a maintenance version was to be released by the end of this
week which fixed the problem. Be it as it may, I'm so sorry that
someone who I appreciate as a colleage may think that all this
complaining is because I want somebody else to do my job. I haven't
mentioned Galicaster not even once, and, in fact, if I were viewing
this question from a vendor's perspective, I would have never said a
word about namespaces. Quite the contrary, I would release my
maintenance version that fixes the namespace issue and never worry
about submitting the patch, and then I could say that *my product is
more compatible with Matterhorn than the official Capture Agent.* How
lame does that sound, that our own agent can't work with our own core,
but someone else's can? And the saddest part of this, what really gets
me on my nerves, is that it seems that *we don't care at all*.
Anyway, next time I'll mind my own business and fix the issue locally.
The last thing I want is starting a fight about something that is
already working.
Rubén Pérez
TELTEK Video Research
www.teltek.es <http://www.teltek.es>
2012/11/7 Ruediger Rolf <[email protected]
<mailto:[email protected]>>
Hi Ruben,
I'm a little confused. We all know that the update of the
namespaces was a notworthy change that had several implications.
But nobody was against the proposal for this update, as far as I
remember.
This current issue seems to me that the Galicaster that is not
maintained by the Opencast community but Teltek and some other
people that are interested in it is not compatible with MH 1.4
anymore because of the namespace changes. (again: correct me if
I'm wrong, I did not follow this issue to much). And now you and
some other people try to provide a backwards compatibility patch,
to make a vendor CA compatible to the upcomming release, which is
probably a good idea.
But who other than you or somebody else assosciated Teltek should
provide this patch? You are not fixing a bug, you want to increase
the compatibility of your device. If you want to achive this you
have to spend as much time on this issue as it takes, you cannot
expect that somebody else is interested in fixing this problem. At
least we in Osnabrück do not care about this and Entwine probably
not too.
Just my 2ct
Rüdiger
Am 07.11.2012 19:03, schrieb Rubén Pérez:
As pointed out by Tobias and Christoph, I added a new patch to
the trunk. Please take a look at it (URL reminder:
http://opencast.jira.com/source/cru/CR-MH-490).
I'm not willing to commit more fixes or dedicate more time to an
issue I didn't cause. If this patch doesn't work, or doesn't meet
the standards, please feel free to commit a new version.
Rubén Pérez
TELTEK Video Research
www.teltek.es <http://www.teltek.es>
2012/11/6 Rubén Pérez <[email protected]
<mailto:[email protected]>>
As discussed in the meeting, I've added Rute's patch to the
trunk. You can see the relevant ticket here:
http://opencast.jira.com/browse/MH-9256.
The corresponding review is here:
http://opencast.jira.com/source/cru/CR-MH-490 . Please feel
free to join and test the patch, and comment whatever you
don't like.
Best regards
Rubén Pérez
TELTEK Video Research
www.teltek.es <http://www.teltek.es>
2012/11/6 Rute Santos <[email protected]
<mailto:[email protected]>>
Hi James,
We had a similar problem when the NCast pr720 was not
sending the namespace and we put a temporary workaround
in place (Ncast has now fixed it). You are welcome to try
it with Galicaster, but I am not sure if it will work...
It's in IngestServiceImpl.java:
@@ -313,7 +325,17 @@
InputStream manifestStream = null;
try {
manifestStream =
manifest.toURI().toURL().openStream();
- mp = builder.loadFromXml(manifestStream);
+ // Hack for ncast BEGIN
+ StringBuffer manifestXml = new StringBuffer(new
Scanner(manifestStream).useDelimiter("\\A").next());
+ if (manifestXml.indexOf("xmlns=") == -1) {
+ int pos = manifestXml.indexOf("<mediapackage");
+ if (pos > -1) {
+ manifestXml = manifestXml.insert(pos + 14,
"xmlns=\"http://mediapackage.opencastproject.org\"; ");
+ }
+ }
+ mp = builder.loadFromXml(manifestXml.toString());
+ // mp = builder.loadFromXml(manifestStream);
+ // Hack for ncast END
} finally {
IOUtils.closeQuietly(manifestStream);
}
Thanks,
Rute
On 11/6/2012 9:42 AM, James S Perrin wrote:
Hi Greg,
On 06/11/2012 14:22, Greg Logan wrote:
On 12-11-06 08:21 AM, James S Perrin wrote:
Hi,
Does anyone have Galicaster (1.2.1)
working with MH1.4/Trunk? We are
able to schedule recordings and they are
captured on the CA (VGA test
with white noise) but when the (default)
workflow has finished there is
nothing to see or hear. The Operations show
that capture has has been
skipped, but ingest and rest of the
operations all succeeded - though
they report no tracks found in the log.
Same CA works with 1.3 so it could be
our inexperience setting up MH
that is the problem.
While I'm not familiar with the way Galicaster
does its ingest, we did
change the XML namespaces on the mediapackages in
1.4. Your symptoms
exactly match what happens when an older
mediapackage is ingested into a
1.4 core, so I suspect that's what's going on.
We've discussed this a
couple of times in the dev meetings, but we
haven't come up with a
proposal to handle this case yet. It's simple to
fix (I do it with a
one line sed script in my study system), just a
matter of someone
writing up the namespace mangling that's needed!
It probably went over my head at the time, still so
much too learn. Gives us a starting point even of we
just fudge Galicaster for now. Is there an issue for
this I can't find one?
Thanks,
James
_______________________________________________
Matterhorn mailing list
[email protected]
<mailto:[email protected]>
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected] <mailto:[email protected]>
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
<mailto:[email protected]>
_______________________________________________
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail:[email protected] <mailto:[email protected]>
Internet:www.virtuos.uni-osnabrueck.de <http://www.virtuos.uni-osnabrueck.de>
_______________________________________________
Matterhorn mailing list
[email protected] <mailto:[email protected]>
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: [email protected]
Internet: www.virtuos.uni-osnabrueck.de
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
