Sometimes fail to start (or uses a very long time to get going)

[petterreinholdtsen]

I just tested with 'vlc https://archive.org/download/LoveNest/LoveNest_archive.torrent', and had to try three times before the video would start playing. I removed the temp file after the second time, to see if it helped. Not sure it affected the result, but it did not hurt either.

[petterreinholdtsen]

I've seen it a few times, and I suspect what is happening is that vlc is picking the wrong part of the torrent to play, and there is nothing to play there.

[petterreinholdtsen]

How exactly is the plugin selecting which file to play when the torrent point to several? The logic seem to need some tuning, as it pick the wrong one once in a while.

[johang]

How exactly is the plugin selecting which file to play when the torrent point to several? The logic seem to need some tuning, as it pick the wrong one once in a while.

There is not logic. It's just adds all files in the torrent to the playlist. See build_playlist in metadata.cpp.

[petterreinholdtsen]

[Johan Gunnarsson]

There is not logic. It's just adds all files in the torrent to the playlist. See `build_playlist` in `metadata.cpp`.

Aha, so it is pure luck that it sometimes actually start playing the video?

…

-- Happy hacking Petter Reinholdtsen

[johang]

Aha, so it is pure luck that it sometimes actually start playing the video?

Well... yeah.

[petterreinholdtsen]

Perhaps it is better to try to locate video files in the stream, or start playing the largest file, or some other heuristics to have a more predictable behaviour?

[johang]

Yes. I'm thinking about some heuristics like filter away all files that don't have image, audio or video file extensions, and the sorting the list. That way you will always have playable items and in predictable order.

[petterreinholdtsen]

[Johan Gunnarsson]

Yes. I'm thinking about some heuristics like filter away all files that don't have image, audio or video file extensions, and the sorting the list. That way you will always have playable items and in predictable order.

Right, sound like a good idea to look at the files to decide how to handle them. Note, believing in extentions is not really very robust. Video files do not need to have an extension, or a recognizable extension.

…

-- Vennlig hilsen Petter Reinholdtsen

[johang]

I can't peek or probe the files. It has to be done when it builds the playlist and that's before files are downloaded. At that time only metadata (filename and file size) is available.

[petterreinholdtsen]

[Johan Gunnarsson]

I can't peek or probe the files. It has to be done when it builds the playlist and that's before files are downloaded. At that time only metadata (filename and file size) is available.

That limit the options, indeed. I suspect size might be a good predictor, as the 'meat' of the package tend to take up most of the space too. Perhaps sort them by size and start playing the largest one is a good idea? If I am not mistaken, it is similar to how the vlc dvdsimple: source work.

…

-- Happy hacking Petter Reinholdtsen

[petterreinholdtsen]

I tested the sort idea using the following patch, and while theplaylist is indeed sorted largest to smallest file, the file selected for playing to do not seem to be affected by the playlist ordering. When trying the Loveboat torrent mentioned above, the ogg file was often selected for playing, even thought it is in the middle of the list. Any idea what is going on here?

diff --git a/src/metadata.cpp b/src/metadata.cpp
index 92d73aa..51a6008 100644
--- a/src/metadata.cpp
+++ b/src/metadata.cpp
@@ -103,6 +103,18 @@ read_stream(stream_t *p_stream, char **buf, size_t *buf_sz)
 	return *buf_sz > 0;
 }
 
+// Functor to compare by the Mth element, from
+// https://stackoverflow.com/questions/23030267/custom-sorting-a-vector-of-tuples#23030402
+template<int M, template<typename> class F = std::greater>
+struct TupleCompare
+{
+	template<typename T>
+	bool operator()(T const &t1, T const &t2)
+	{
+    		return F<typename std::tuple_element<M, T>::type>()(std::get<M>(t1), std::get<M>(t2));
+	}
+};
+
 static bool
 build_playlist(stream_t *p_demux, input_item_node_t *p_subitems, char *buf,
 		size_t buf_sz)
@@ -137,27 +149,30 @@ build_playlist(stream_t *p_demux, input_item_node_t *p_subitems, char *buf,
 	// Bencode metadata and dump it to file
 	bencode(std::ostream_iterator<char>(out), t.generate());
 
-	std::vector<std::string> files;
+	std::vector< std::tuple<boost::int64_t, std::string> > files;
 
 	for (int i = 0; i < metadata.num_files(); i++) {
-		files.push_back(metadata.file_at(i).path);
+		files.push_back(std::tuple<boost::int64_t,
+				           std::string>(metadata.file_at(i).size,
+							metadata.file_at(i).path));
 	}
+	std::sort(files.begin(), files.end(), TupleCompare<0>());
 
 	input_item_t *p_current_input = input_GetItem(p_demux->p_input);
 
 	// How many characters to remove from the beginning of each title
 	size_t offset = (files.size() > 1) ? metadata.name().length() : 0;
 
-	for (std::vector<std::string>::iterator i = files.begin();
-			i != files.end(); ++i) {
+	for (std::vector< std::tuple<boost::int64_t, std::string> >::iterator i = files.begin();
+	     i != files.end(); ++i) {
 		std::string item_path;
 
 		item_path += "bittorrent://";
 		item_path += path;
 		item_path += "?";
-		item_path += *i;
+		item_path += std::get<1>(*i);
 
-		std::string item_title((*i).substr(offset));
+		std::string item_title((std::get<1>(*i)).substr(offset));
 
 		// Create an item for each file
 		input_item_t *p_input = input_item_New(

[petterreinholdtsen]

I created pull request #15 with the predictable playlist ordering. It do not solve this issue, but predictable behaviour seem like a good idea anyway.

[petterreinholdtsen]

Hi, did you make any progress on improving this? The new Debian version freeze is only a few weeks away, and I hope to get updates in before the freeze happen.

[johang]

Yes, I have been working in a rewrite of the plugin. I might make a v3.0 soon. Can't promise anything though.