SOLVED

Stream group video count incorrect

Iron Contributor
I am using a public group with 38 channels and most of the videos are in more than one channel. I have loaded about 50 videos into the channels in that group. When I browse groups, it shows 38 channels and 170 videos. The channel count is correct, but it looks like it is counting the videos multiple times based on the number of channels a video is in.
4 Replies
best response confirmed by Rick Palm (Iron Contributor)
Solution

Thanks for reporting this. We'll take a look. This would be a bug on our side :(.

Hi, Rick,

 

I am looking into this issue. Can you please provide more information for us to get started?

1. Does this issue still remain?

2. What are your tenant id and user id? 

 

If you don't know your tenant/user ids, can you send us the session id (log in to web.microsoftstream.com, on top-bar, click "?" button at the right top corner. Click "About Microsoft Stream" in the drop down. Copy/paste session id and "Your data is stored in" and send us.

 

Thanks 

Rick, no worries. I can repro this internally. We are investigating the root cause. Will follow up with you when we know more.

@Lin Liu (IIS) Was this ever resolved? We have it happening in our MS Stream instance also.

I have a group with reads it has 226 videos in the group, but when you add up the video counts for each channel within the group, it comes to 357ish.

 Yes I know they are sunsetting MS Stream...but we are trying to figure out our level of effort to download literally 1000's of videos and trying to gauge the number of hours to do this, thus we are looking to see what the amount of total videos is that needs to be manually migrated. (Our SPO Team tells us there's no migration tool for videos going from Stream to SPO. Which sucks.)

I've assumed that maybe someone may have linked a video to a channel, that doesn't exist in the group? But now I'm not sure?

1 best response

Accepted Solutions
best response confirmed by Rick Palm (Iron Contributor)
Solution

Thanks for reporting this. We'll take a look. This would be a bug on our side :(.

View solution in original post