On 12-11-07 04:49 PM, Ruediger Rolf wrote: > 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.
Anyone with a CA expecting a 1.3 or older core will encounter the same issue. For instance, I can see a situation where a university has a number of reference CAs in the field and then upgrades their core. This institution would then need the patch. Not to put words in Rueben's mouth, but my understanding is that Teltek is going to update their implementation once 1.4 is formally shipped. Users using Galicaster at the moment are running into the issue because they are using pre-release code in a production environment. The patch as it is in trunk is a good workaround. I'll have to port it to 1.4, but it should make the next RC so people can start testing with it. G > 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] >> 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] > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
