[Core] No Preview available

[Frans]

---

0016675: 1 [Core] Geen Preview beschikbaar
 http://mantis.kennisnet.nl/view.php?id=16675

De EGA play URL is leeg. Hier verwacht SURFmedia de flash preview, zoals in de vorige releases werd gedaan.

Deze zal opgelost worden in 1.7
(0027275)
SURFnet - Frans (manager)
2009-07-22 10:52

Dit issue staat nog open voor de afronding van 1.5

Het zorgt ervoor dat SURFmedia meldt dat er 'geen preview' is van master-slave materiaal, terwijl er wel een preview aanwezig is. oorzaak is dat de 'ega_play_url' door de core niet gevuld wordt met transcode_id 13 mediafile terwijl deze mediafile wel aanwezig is. Graag hoor ik vandaag of de core dit nog kan oplossen met een patch voor livegang SURFmedia, of dat wij naar een workaround toe moeten werken.
(0027126)
schok01 (manager)
2009-07-01 15:32

ega_play_url lijkt niet goed te werken over 'master-slave' heen.

Op VPcore acceptatie-omgeving staat asset 1Afl4ITItvn5Xx127pHnjLPF van het NIBG (app=3), met twee mediafiles (origineel (wmv) en flash transcode volgens profile 13). Beide mediafiles hebben een acl met aut_app=5.

Als ik vanuit app 5 (VIP test) een
/asset/1Afl4ITItvn5Xx127pHnjLPF doe, dan krijg ik een lege <ega_play_url></ega_play_url>.

Het omzetten van 'default transcoding profiel' voor NIBG van 1 naar 13 maakte geen verschil.

De /asset/ call vanuit NIBG levert wel een gevulde ega_play_url op.

[MC-arjen]

released in 1.7.0.1

[Frans]

(MC-arjen) <ega_play_url> didnt work correctly with master/slave
records. This was in fact fixed earlier with a related OAI change.

[Michiel.Schok]

I'm not sure what goes wrong... Please check the following situation.
When SURFmedia issues an /asset call for an own asset (no master/slave), the response goes as follows:

<request_uri>[GET] asset/PuCOe94mJv7PNOBOK8nbKji8</request_uri>
...
</czp>
      <ega_play_url>http://www.20.test.surfmedia.nl/app/video/PuCOe94mJv7PNOBOK8nbKji8/play?format_id=Msp4G3zGnd7Y91WTC4rhJffv</ega_play_url>
      <is_favorite>FALSE</is_favorite>
...
      <mediafile id="2">
          <mediafile_id>Msp4G3zGnd7Y91WTC4rhJffv</mediafile_id>
...
          <transcode_profile_id>13</transcode_profile_id>
...
          <ega_play_url>http://www.20.test.surfmedia.nl/app/video/PuCOe94mJv7PNOBOK8nbKji8/play?format_id=Msp4G3zGnd7Y91WTC4rhJffv</ega_play_url>
...

In there is (just below the czp-metadata) an <ega_play_url> which points to the <ega_play_url> of the mediafile with the preferred transcoding. Preferred transcoding can be configured in the management portal. For SURFmedia, this happens to be '13'.

When issuing an /asset call on a master-slave asset from app-id 3, there is no <ega_play_url>, but instead is an empty <ega_view_url></ega_view_url> on the same spot as in the previous example.

[GET] asset/30092
...
      </czp>
      <ega_view_url></ega_view_url>
      <is_favorite>FALSE</is_favorite>
...
      <mediafile id="3">
          <mediafile_id>IGtuTdL2QI7MAVplugmjIc9Q</mediafile_id>
...
          <transcode_profile_id>13</transcode_profile_id>
...
          <ega_play_url>http://www.20.test.surfmedia.nl/app/video/30092/play?format_id=IGtuTdL2QI7MAVplugmjIc9Q</ega_play_url>

Please clarify, SURFmedia expected the same behaviour as on its own assets.
SURFmedia has implemented a work-around, we now hunt for the right mediafile and use the <ega_play_url> for that asset.

I even tried adding ?aut_realm=@… to change the 'granted' field to true, to see if the empty <ega_view_url> would change, but that was not the case.

Tested, not accepted, reopened. Priority change to minor because there is an active, working workaround in SURFmedia.

[MC-arjen]

As it turnes out the ega_play_url is only generated when the mediafile has technical metadata; not sure if this is an expected behaviour. Assigned to Michiel for feedback here.

Also we would like to do some more tests with OAI (where this field is also used.) Postphoned to 1.7.2

[Michiel.Schok]

As it turnes out the ega_play_url is only generated when the mediafile has technical metadata; not sure if this is an expected behaviour. Assigned to Michiel for feedback here.

Yeah, that is correct. We expect the ega_play_url at the asset level to be filled with the ega_play_url of the preferred transcoding.

At the moment there is a difference in XML-response whether we do an /asset call on a Master-Slave asset (from MIBG), or an /asset call on our own assets. See responses above. On our own asset, we get it correctly filled, on a Master/Slave? asset, the ega_play_url doesn't even exist in the XML-response, but instead we get an empty ega_view_url in the response.

Main concern now is consistency between own assets and master/slave assets.

Anyway, if no ega_play_url is found, SURFmedia at the moment iterates through all mediafiles, looking for the mediafile with transcode id 13. We no longer depend on the availability of the ega_play_url on the asset-level. Of course we use them a lot in the mediafile context.
We see future possibilities to use the new play-call using a transcode profile id, or provide a 'preview' tag on a mediafile, and use such a call to find the right mediafile to preview.

In general, it would be wise to document the 'general XML' format so that it is clear what to exepect.

Also we would like to do some more tests with OAI (where this field is also used.) Postphoned to 1.7.2

I don't think it's wise to use the ega_play_url in OAI.

---

When we issue a call like below on Core-production, we observe the same behaviour, difference in response. But now, the two methods are visible in the same response because we perform a search which returns two assets, one NIBG and one SURFmedia:

[get] /asset?limit=10&description=legendarische+winter

<items>
    <item id="1">
      <asset_id>40672</asset_id>
      ...
      <dublin_core>
...
      </czp>
      <ega_view_url></ega_view_url>
      <is_favorite>FALSE</is_favorite>
      <granted>TRUE</granted>
...
    </item>
    <item id="2">
      <asset_id>RsRbHgmuJB897KIeWzdb6MXs</asset_id>
...
      <dublin_core>
...
      </czp>
      <ega_play_url>http://www.surfmedia.nl/app/video/RsRbHgmuJB897KIeWzdb6MXs/play?format_id=8DUF2r52kqyYv1JtN2Z6TH4n</ega_play_url>
      <is_favorite>FALSE</is_favorite>
      <granted>TRUE</granted>
...
    </item>
  </items>

[Frans]

Moved to MediaMosa 2.1

[Frans]

Needs discussion

[Frans]

SURFmedia has implemented a workaround. Will close.