Listen: grp's "playlist-3" and "playlist-4" do not play

[Brahmanathaswami]

They return:

[Brahmanathaswami]

git: There come up on "nightly"

compare nightly behavior_Listen

and listen-5 behavior_Listen

    it should be  easy to  fix

[soapdog]

This appears to be related to the arrays having the wrong elements in them, as can be seen in the screenshot below:

[soapdog]

My suspicion is that the code that fetches and caches data is buggy, or that the server part is answering with bad content.

[soapdog]

Data is loaded from a json file at modules/listen/collection.json. This json doesn't contain the fields that the code is attempt to access for some collections, as can be seen below:

{
        "playListTitle": "Bodhinatha's\nLatest",
        "playListImg": "bodhinatha-latest_330.jpg",
        "playlistClass": "latest",
        "recordType": "latest",
        "recordCount": "30",
        "data_query": {
          "media_type": "inspiredtalk",
          "author": "Satguru Bodhinatha Veylanswami",
          "approved_for_public": "YES"
        }
      },
      {
        "playListTitle": "Classical\nArtists",
        "playListImg": "professional_rajam-singer_330.jpg",
        "playlistClass": "cached",
        "data_query": {
          "media_type": "audio/song",
          "tags": "Professional",
          "approved_for_public": "YES"
        }
      },
      {
        "playListTitle": "Popular Tunes",
        "playListImg": "popular-tunes-lady-headset_shutterstock_330.jpg",
        "playlistClass": "cached",
        "data_query": {
          "media_type": "audio/song",
          "tags": "pop",
          "approved_for_public": "YES"
        }
      }
    ]
  },

The first item in the snippet above has recordType and recordCount, but the two items next to it don't.

[soapdog]

Then the code proceeds to fetch data from the bundled jnanam database. I've altered fetchMediaItems function in lib_SivaSivaMedia because it was using string functions to search for numbers. I believe that this change might be leading to this problem as the string comparison being used requires the match to be exact and not partial.

Changed code, notice the dbLike command requiring exact matches:

[soapdog]

Yes, that is the source of the problem. fetchMediaItems needs to use partial match or it won't be able to match tags.

A shot below is showing and example result with partial matches, notice the tags field.

Using partial matches in that code will lead to false matches for some cases as some words are part of other words. For example, if we change it to a partial match, searching for Guru will also match Gurudeva and Satgurus, which are different tags.

[soapdog]

In the original bug submission, @Brahmanathaswami wrote

git: There come up on "nightly"

compare nightly behavior_Listen

and listen-5 behavior_Listen

    it should be  easy to  fix

I just want to highlight that these are not easy fixes and they were not related to behavior_Listen. The code in this app has some extreme tight couplings and is very convoluted with handlers that are overloaded with special behaviours and side-effects depending on which parameters are passed to them. Solving bugs in this app require one to explore a lot of behaviours and libraries.

---

In summary, there was a bug in lib_SivaSivaMedia that was fixed a month ago. It was using string comparison SQL code to find numbers. This meant that searching for item_id = 11 would return 11, 111, 1011 and any number that had two ones next to one another.

When the fix was written, the dbLike clause for string comparison was made to be an exact match, so that searching for guru would not return partial matches such as satguru and gurudeva.

This in turn broke playlist_FetchData in behavior_Listen because it is searching for tags and tags are a comma-delimited list, so the only way to search them with "LIKE" is to use a partial match.

The commit to fix this issue, reintroduces partial matches with a special case just for tags fields. This will necessarily introduce a bug in which words that have the same letters are other words will cause a match.

[soapdog]

So this is fixed with caveats.

[Brahmanathaswami]

I did a Git pull on listen-5.

git log --> fetchMediaItems --> This closes #287

But still need to do something to fix this?

[soapdog]

That bug happened because fetchMediaItems uses EXACT MATCHES for all fields except tags and whoever created the JSON didn't fill the complete information for the media_type of that collection.

It was working before because the code for fetchMediaItems was using partial matches for everything, which is wrong.

Fixing the collection.json entry to be audio/inspiredtalk made it work.

I see that you're relying on a partial match for the recent additions, that can be done by changing it from audio to audio% and being explicit about how the matching should work.

I just spent some time checking the source to learn that recent additions are coming from the server even though they are placed in collection.json with properties similar to the ones that are being searched in the local db. That is confusing.