showfed datastream display problem

Project:RUcore dlr/EDIT
Category:bug report

The following two objects on rep-devel do not display the
same number of datastreams in a search result and in the
showfed display.

Search result shows FLV-1, MOV-1
showfed just FLV-1

Search result shows PDF-1, MOV-2
showfed just PDF-1


These were part of the 17 errors from the backlabels project on rep-devel, but it
maybe more widespread than just these two examples.



Thanks Dave. I'll look into this one.


At least the MP-4 issues are a matter of bad data in the objects. These two objects have MP4 test datastreams with the mimetype simply "mp4" rather than "video/mp4", which causes the Fedora process to fail. I changed the mimetype on these two datastreams to video/mp4 and was then able to change the labels. The other issue is a bit different. I'm looking into that.


Assigned to:triggs» dhoover
Status:active» test

Good bug Dave! Thanks! It should be fixed now.


Assigned to:dhoover» triggs

The order of the datastreams is fixed.

I believe the bad mime type can also be seen on a number
of the failed records from the backlabels run. In particular
if you look on rep-devel at /tmp/dh there is a list
of the ones that failed and if you follow them into fedora
you will see what i mean.

Mainly it seems like ones that are for PDF files and list
the MIME type as PDF . I only mention this because you
fixed the mp4 ones.

Of the 18 that failed backlabels (see /tmp/dh on rep-devel)
these are the MIME types

<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">image/jpeg</td>
<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">application/pdf</td>
<td align="left">PDF</td>
<td align="left">video/mp4</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">PDF</td>
<td align="left">application/zip</td>
<td align="left">application/zip</td>
<td align="left">application/x-spss-por</td>
<td align="left">video/mp4</td>


Sorry that should have read the same datastreams are now displaying
for both search results and showfed


The mimebacklabels.php script now looks for PDF as a bad mime in addition to empty and unknown and changes them before attempting to change the labels.


Display problem is fixed.


There may be other invalid mimetypes. How do you plan to identify and fix them? Is it possible to identify invalid mimetypes in a systematic manner?



The main issues have to do with mime types given as "unknown" and simply "PDF" or "MP4". backlabels now checks for these. We could create a test of the mime types on all the datastreams and fix them if necessary.


Status:test» closed

Closing this bug. I am ignoring the mime type comment since it is another issue.

Back to top