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 2012/11/7 Ruediger Rolf <[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 > > > > 2012/11/6 Rubén Pérez <[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 >> >> >> >> 2012/11/6 Rute Santos <[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] >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> [email protected] >>> _______________________________________________ >>> >> >> > > > _______________________________________________ > Matterhorn mailing > [email protected]http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please [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] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
